NeXT Education Software Sampler 1992 Fall

home *** CD-ROM | disk | FTP | other *** search

/ NeXT Education Software Sampler 1992 Fall / NeXT Education Software Sampler 1992 Fall.iso / Programming / Source / winterp-1.13 / doc / winterp.doc < prev next >

Wrap

Text File | 1991-10-06 | 309.9 KB | 8,857 lines

-*-Outline-*- ================= = W I N T E R P = ================= T H E O S F / M O T I F W I D G E T I N T E R P R E T E R An interactive object-oriented user interface language for rapid prototyping, development and delivery of user-extensible applications with Motif GUIs. Version 1.13 October 5, 1991 by Niels P. Mayer Human-Computer Interaction Department Software and Systems Laboratory Hewlett-Packard Laboratories Mailing Address: Hewlett Packard Niels Mayer 1U/17 P.O. Box 10490 Palo Alto, CA 94303-0969 E-Mail Address: internet: mayer@hplabs.hp.com uucp: hplabs!mayer ******************************************************************************** * WINTERP Copyright 1989, 1990, 1991 Hewlett-Packard Company (by Niels Mayer). * XLISP version 2.1, Copyright (c) 1989, by David Betz. * * Permission to use, copy, modify, distribute, and sell this software and * documentation for any purpose is hereby granted without fee, provided that * the above copyright notice appear in all copies and that both that copyright * notice and this permission notice appear in supporting documentation, and that * the name of Hewlett-Packard, Niels Mayer, and David Betz not be used in * advertising or publicity pertaining to distribution of the software and * documentation without specific, written prior permission. Hewlett-Packard, * Niels Mayer, and David Betz make no representations about the suitability of * this software and documentation for any purpose. It is provided "as is" * without express or implied warranty. * * HEWLETT-PACKARD AND DAVID BETZ DISCLAIM ALL WARRANTIES WITH REGARD TO THIS * SOFTWARE AND DOCUMENTATION, INCLUDING ALL IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL HEWLETT-PACKARD, NIELS * MAYER, NOR DAVID BETZ BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF * THIS SOFTWARE AND DOCUMENTATION. ******************************************************************************** * Document Version: $Header: winterp.doc,v 1.21 91/10/06 07:16:45 mayer Exp $ ******************************************************************************** * Introduction ** Why a Widget INTERPreter? WINTERP is an interpretive, interactive environment for rapid prototyping applications using the OSF Motif UI Toolkit. The name "WINTERP" stands for Widget INTERPreter, and that's exactly what WINTERP is -- an interpretive language that allows programmers to interactively create interfaces using the capabilities of the Motif widgets and the X11 toolkit intrinsics. Widgets in the Xtoolkit are dynamic and "interpretive" by nature of their object-oriented, message passing style of design; they become maximally useful when driven by an interactive environment like WINTERP. Neither traditional C Xtoolkit applications, nor UIL applications really take advantage of the interpretive nature of the Xtoolkit. When programming in C, one is forced to go through tedious compile+edit+test cycles even for making a trivial change. X and the Xtoolkit provide a fancy widget resource manager that allow you to shorten the compile+edit+test cycle -- the Xtoolkit "reinterprets" it's resource settings as a whole each time the application is brought up; compile+edit+test is shortened to edit+test. UIL extends the level of data-interpretation a little bit further by allowing the system to read a structured description of the widget hierarchy and resources. UIL claims this will allow applications to be written in such a way that the interface can be drastically altered by changing the description file. In reality, only the most trivial sorts of layout changes are possible with UIL because it is not a programming language, and thus cannot allow you alter the program semantics that are invariably intertwined with the semantics of the user interface. Furthermore, UIL still uses compilation, rather than interpretation, which means application prototyping is still as tedious as ever. WINTERP provides both an interpretive interface to the Xtoolkit widgets, and a real programming language -- this makes it ideal for prototyping and/or customizing the layout, look, AND functionality of an application. WINTERP's interpreter is based on David Betz's popular XLISP, a small, fast, C-implemented interpreter with Common Lisp syntax and extensions for object oriented programming. Full-blown Lisp systems such as Common Lisp have proven to be very effective prototyping environments and are commonly used as platforms for building User-Interface Management Systems (UIMS). WINTERP attempts to deliver the advantages of Lisp to those that cannot afford the expenses, both monetary and computational, of large systems like Common Lisp. Lisp is traditionally associated with unwieldy, large, slow and expensive systems -- Lisp's flexibility has it's costs. One solution to these problems has been to create special operating systems and hardware to better support Lisp: The Lisp Machine -- a very expensive, and very specialized system. Lisp Machines are losing ground to the general purpose workstation running UN*X: such machines can be built at relatively low cost with enough compatibility between vendors that a growing number of UN*X applications can be run on a variety of hardware vendor platforms. Unfortunately, attempts at building Lisp-based applications that are good citizens on UN*X workstations have generally failed because systems such as Common Lisp (CL) create huge, resource-hungry processes that swap/thrash out all other applications -- not acceptable if you are trying to create an application that works alongside other applications running in a multiprocessing system like UN*X. While CL platforms will continue to make excellent prototyping platforms, delivery of applications embedded in a CL environment is unacceptable. Attempts at recoding CL prototypes under a delivery platform (e.g. just using UN*X & C) is time consuming, and changes the feel and the flexibility of an application: applications prototyped with Common Lisp assume and make use of the underlying features of the Lisp system; these assumptions must be removed from the design or be recoded in the delivery language. Fortunately, another class of Lisp application has been successful in a general purpose computational environment -- a hybrid architecture of Lisp and C giving the flexibility of a Lisp system while allowing delivery of a relatively small and efficient process. Under UN*X, Richard Stallman has created a highly-customizable editor-based programming environment called GNUEMACS -- this is a system that delivers to the UN*X user a text editor oriented UI that is the foundation of the Lisp Machine programming environment. Similarly, under MSD*S successful programs like AUTOCAD contain a Lisp customization language embedded in a CAD program. The approach taken by such hybrid applications is that a small mini-Lisp interpreter serves to "glue" together efficient C-implemented primitives that make up an application. User-customization and prototyping under such a hybrid system amounts to using the Lisp interpreter to reconfigure C-implemented building blocks in order to change, modify, or improve the functionality of the system. Such an application architecture follows the "80/20 heuristics" for program execution -- low level routines that take up most of the computational resources are coded in C, and are therefore fast, and efficient in memory use (no garbage collections caused by low-level code). The Lisp interpreter is relatively slow in comparison to a compiled C program, but it only serves to flexibly glue together components of the "outer loop" of a program. WINTERP was written as a platform for building such hybrid Lisp/C systems; XLISP makes this possible because, unlike large Common Lisp systems, integrating arbitrary C-implemented functionality with the Lisp interpreter is easy. WINTERP itself is an example of the feasibility of hybrid programming techniques -- WINTERP's X/Motif functionality is achieved through XLISP interfaces to the C-implemented Motif toolkit. WINTERP is thus aimed at the class of application that cannot afford to carry along all the excesses of Common Lisp, but does require an embedded programming language for user-customization. WINTERP supports an evolutionary program lifecycle: WINTERP application writers will rapidly prototype new functionality by using the mini-Lisp interpreter to interactively refine the layout, looks, and functionality of the user interface. Once functionality has stabilized, a programmer will be able to improve the application's efficiency by reimplementing the functionality in C while maintaining the same Lisp programmatic interface to the rest of the system. These new primitives will then serve as the building blocks for the next layer of prototyping and customization... The end result, if designed carefully, is a relatively small and fast application that provides the right set of building blocks and hooks to permit end-users to customize the look and feel of the application. WINTERP is also useful for rapid prototyping applications that do not need to be delivered with an embedded customization language. Systems with such delivery goals may still use the aforementioned application lifecycle. As the application matures and Lisp prototype code stabilizes, the program can gradually be recoded entirely into C, eventually allowing a "normal" C program to be delivered. ** Why I built WINTERP: I built WINTERP as a platform for our project in designing, building, and evaluating Computer Supported Cooperative Work (CSCW) and Collaborative Multimedia Systems. The usefulness of such systems can rarely be demonstrated by demoing "laboratory curiosity" applications; evaluating such technologies requires applications be delivered to early adopters of the technology with a minimum of extraneous overhead (e.g. runtime licenses, huge systems) and that the delivered application be customizable so that it can be integrated into the environment of a particular workgroup. The project's immediate goal is to develop STRUDEL, a highly configurable mail/calendar/information management system to enable computer supported cooperative work. We intend for STRUDEL to become the "GNUEMACS of groupware systems". The Lisp interpreter will permit the system to be customized to support special modes of communication for particular workgroup environments much in the same way that emacs-Lisp is used to customize the editor to support special editing modes for particular programming environments. In STRUDEL, WINTERP's Lisp interpreter and Motif U.I. primitives will be used as a description language for creating and processing active/graphical e-mail forms. Such forms can be sent (as textual programs) through standard e-mail channels, and the receiving STRUDEL system will interpret the WINTERP-Lisp forms description language and display a form letter containing a user interface built from arbitrary combinations of widgets, bitmaps, as well as voice and video "widgets". Users will be able to choose from a library of email forms that are designed to track specific types of conversations -- scheduling meetings and resources, software defect tracking, fleshing out design issues, etc. Workgroups can extend the library of forms to help capture and manage recurrent conversations that are not covered by STRUDEL's standard forms library. ** Why XLISP? I implemented WINTERP on top of XLISP because it is reliable, small, and free, thus allowing delivery of applications such as STRUDEL (see above) with a minimum of overhead (licenses, slow systems requiring specialized hardware) to potential early adopters of groupware technologies. XLISP has been around since 1985, and has evolved considerably since it first appeared publically; because it has been in use for some time it has also had most bugs shaken out of the system through widespread use. Furthermore, the newsgroup comp.lang.Lisp.x has been an effective channel for exchanging information and patches to XLISP. XLISP was designed to be run on PC's; because it was designed with a limited environment in mind, it has turned out to be quite fast and memory- efficient while remaining portable across a variety of architectures ranging from 16 bit PC's to workstations. And of course, XLISP's simple object system has enabled an elegant interface to the object oriented structure of the Xtoolkit and the Motif widgets. Finally, XLISP is free, thanks to the generosity of David Betz. Many people have asked "Why not scheme?", or "why not emacs-Lisp?"... the above paragraph should answer that. David Betz's XSCHEME is still under development, and would not be a good choice as a stable platform. In particular, XSCHEME does not (yet) have the debugging capabilities of XLISP. Other Scheme implementations were too large, and too complicated to work with given the sorts of changes I needed to make. GNUEMACS' emacs-Lisp fit the bill in many ways, but unfortunately the code is very intertwined with GNUEMACS' editor functionality, and the Free Software Foundation's Copyleft is far too restrictive to be used in potential products built from WINTERP's technology. "Professional" Common-Lisp systems have many nice features, but unfortunately, they are big, slow, expensive, and make bad delivery platforms. Most CL systems do not come with source code, which makes it difficult to alter the way these systems work in significant ways (as I have done with XLISP in WINTERP). Even with source code, CL impedes the use of hybrid programming techniques mentioned above -- CL systems are often only implemented in C at the lowest levels, thus making it difficult to patch in high-level C-implemented functionality that can be used transparently from Lisp. Finally, Common Lisp programs cannot be distributed for free -- this means that potential early adopters of our STRUDEL technology would have to pay CL license fees, attach codeword modules to their computers (to ensure that license fees have been paid), and other such "hassles". People eager to try out our STRUDEL technology may have second thoughts about becoming "early adopters" if they have to spend money and time (convincing their management to give them the money and time ...) in order to try out experimental software. ** Interactive GUI programming with WINTERP -- the XLISP eval server. When running a Winterp-Lisp application "script", the WINTERP program runs just like a normal C and Motif program under X windows. The advantage WINTERP has over other user-interface pseudo-languages (like Motif's UIL or Brunecky&Smythe's WCL) is that you can interactively create or modify user interfaces while one's application is up and running. This is essential for rapid prototyping; this is the reason why WINTERP is a rapid prototyping environment and UIL and WCL aren't. Many other UI languages including many Lisp interfaces to X (CLX, Garnet, etc), have separate "modes" for when they are responding to X and evaluating language input. The problems with such systems is that they do not allow for interactive prototyping -- when X is active, programmatic changes cannot be made, and when the language-evaluator is active, programmatic changes cannot be visualized. WINTERP allows for interactive X programming because its language-input is implemented via a server socket; programmatic input is treated as an event that is dispatched from the X event loop. The clients of WINTERP's evaluation server are editors/programming-environments such as GNUEMACS, or any other program running on other UN*X machines on a network. Such capabilities are extremely useful in allowing "remote procedure calls" (RPC) to a WINTERP-based application. The GNUEMACS editor provides a very elegant and useful environment for editing Lisp programs and interacting with WINTERP's Lisp eval-server. Emacs' Lisp-mode will automatically indent your code (C-M-Q == indent-sexp) and help you catch unmatched parentheses. The file ./../src-client/winterp.el extends Emacs' Lisp-mode by providing a command that allows you to send the current Lisp form you are editing off to WINTERP for evaluation. This allows truly interactive programming because you need not exit the editor to see the results of your "program"; with WINTERP's emacs interface, each fragment of Winterp-Lisp code written into the editor can, at the touch of a button, be evaluated; programmatic changes affecting the user-interface can be visualized immediately. Note that WINTERP is architecturally separate from the GNUEMACS editor -- interfaces to other editors are possible, but are not provided in the standard WINTERP distribution. (I strongly recommend that those that don't know how to use Gnu-Emacs should learn how -- you'll never be sorry, and besides, Emacs is really the only editor appropriate for doing Lisp programming. Even commercial Common Lisp vendors tend to use Gnu-Emacs as the preferred editing environment for their products, simply because Gnu-Emacs is the best Emacs implementation running on Unix. Another big advantage to gnu-emacs is that it runs under Xwindows directly, which means that you can select the Winterp-Lisp expression you want to evaluate by pointing at it with the mouse... For those that do not have Gnu-Emacs on their systems, or who do not want to learn Gnu-Emacs to use WINTERP, a rudimentary alternative is provided: see the Winterp-Lisp file ./../examples/w_ctrlpnl.lsp as well as the descriptipon of the WINTERP Control Panel Below.) The WINTERP distribution contains a simple client program 'wl' (in ./../src-client/wl) which sends the Lisp s-expression given on its command line to the Lisp server for evaluation. 'wl' may be embedded in other programs that need to talk to WINTERP-based applications. 'wl' can also be called (e.g., via system(2)) from such programs -- that is essentially how WINTERP gets gnuemacs to talk to it. WINTERP's RPC capabilities can enable better tool integration: different tools in one's environment can easily communicate with an application built upon WINTERP. For example, in the aforementioned STRUDEL project, we expect to integrate the groupware toolkit with traditional, stand alone software revision control and source control tools so that designers can keep better track of conversations on-, commitments about-, and issues surrounding- version ownership, defect and enhancement resolution, etc. * Prerequisites and Assumptions. This documentation assumes that you understand object oriented programming concepts, understand the rudiments of Lisp programming, and know how to make application user-interfaces using the Xtoolkit. If not, you should be able to learn things quite easily by studying and interactively evaluating the various bits of Winterp-Lisp code in the ./../examples directory. For documentation on XLISP features see the files ./../doc/xlisp.doc, ./../doc/XlispRef.doc and ./../doc/XlispOOP.doc . This guide assumes that you already have documentation on Motif and the Xtoolkit. A good overview of programming with widgets is Doug Young's "X Window Systems: Programming and Applications with Xt." I also expect that you have the Motif programming guide, the Motif manual pages, etc. This document will hopefully allow you to understand how to translate the examples and topics discussed in those programming guides into WINTERP-Lisp. Names in Xtoolkit and Motif contain mixed case. Since XLISP symbols are case-insensitive, all the Motif/Xtoolkit names in WINTERP contain an underscore in place of a lowercase-to-uppercase transition in the name, eg, xmPushButtonWidgetClass becomes XM_PUSH_BUTTON_WIDGET_CLASS, and the resource XmNinput becomes :XMN_INPUT. All the Xtoolkit/Motif C names are listed in close proximity to the Winterp-Lisp names for equivalent functions. Therefore, to look up the Xtoolkit name "XtFoo", use your editor to search (in Gnu-Emacs, use i-search) for occurences of "XtFoo" in this document. This document is written in plain-text so as to make it easier to use on-line -- if you are viewing it in emacs, you will find some of the outline-mode commands useful. WINTERP version 1.11 supports OSF/Motif 1.1 and OSF/Motif 1.1.1. The source has been #ifdef'd for backwards compatibility for people still using Motif 1.0 -- the same source may be used to provide binaries for WINTERP running either version of Motif. This document is also "#ifdef'd" so as to indicate which names and functionality apply to Motif 1.0, and to indicate new functionality brought on by Motif 1.1. Descriptions in this document that apply only to Motif 1.1 (and Motif 1.1.1) are bracketed by "#ifdef MOTIF_1.1" and "#endif /* MOTIF_1.1 */". Description pertaining only to Motif 1.0 are bracketed by "#ifdef MOTIF_1.0" and "#endif /* MOTIF_1.0 */". * Introduction to XLISP objects and Widgets. WINTERP uses XLISP's object system as its interface to the class hierarchy of widgets provided by Motif. Specifically, each Motif widget class is represented by one or more object classes in WINTERP. In order to best understand the capabilities of WINTERP's Motif interface, a brief review of the XLISP object system is in order. You may also want to consult the XLISP documentation ./../doc/xlisp.doc and ./../doc/XlispRef.doc for a more precise definition of the object system. Further examples may be found in file ./../doc/XlispOOP.doc, Tim Mikkelsen's "XLISP 2.0 OBJECTS PRIMER." XLISP Classes describe the type of a particular object by declaring a set of variables held in each object. These "instance variables" may only be accessed by "methods" that respond to "messages" sent to the object. Methods are defined for particular classes, and functionality of other classes may be incorporated into new classes via "inheritance". From XLISP, Motif widget classes look just like normal XLISP objects -- that means that you can easily extend the functionality of Motif widgets by adding your own methods to a particular widget class. You may also use inheritance to attach your own data structures to widgets. The result is that WINTERP provides a very clean way to interactively rapid-prototype an application, while also providing mechanisms for code structuring and reuse. The latter is necessary in evolving from prototype to a structured, maintainable, and customizable deliverable. ** Creating new objects. Create a new instance of a class by sending the message :NEW to <a_class_instance>: (SEND <a_class_instance> :NEW <parameters>) <a_class_instance> is in fact an instance of class CLASS. Class CLASS allows you to define new class instances by specifying the instance variables and parent class of a particular class. ** Declaring a class. To declare a "base class" object, that is, an object with no parent object, just send message :NEW to the object <CLASS> (SEND CLASS :NEW '(<ivar0> ... <ivarN>) ['(<cvar0> ... <cvarM>)]) '(<ivar0> ... (ivarN>) are a list of symbols. Each <ivar-i> names an instance variable of the class. '(<cvar0> ... <cvarM>)]) are an optional list of variables that are shared among all instances of that particular class. ** Defining methods. When a "message" is sent to an object, XLISP searches for a "method" to answer the message. A method is a piece of Lisp code that is executed when a particular message is sent to an object. Within the code of a method, all object instance and class variables are accessible. Furthermore, the symbol 'self' is bound to the object the message was sent to. Methods are defined by sending the message :ANSWER to <a_class_instance>: (SEND a_class_instance :ANSWER <:msg> <parameters> <code>) where <:msg> is a keyword symbol (a symbol with a ':' prefix) representing the message; <parameters> are the arguments given along with the message. See the documentation on "lambda lists" in /winterp/doc/xLisp.doc p.12 for details. <code> is a list of s-expressions which get evaluated in response to a message. The lexical environment that existed for the call to :ANSWER will be used for value and functional bindings during method evaluation. If you need to remember what the syntax is, consider the memory-helper "this class :ANSWERs to :MESSAGE..." == (send <cls> :ANSWER :MESSAGE ...) ** Inheritance So far, the object system we just described supports *encapsulation*. Encapsulation is good programming practice because it helps localize and detangle complexity. Unfortunately, encapsulation runs counter to flexibility because making flexible use of an object may require that certain groups of instance variables be accessed by different layers of new functionality. Most often, one wants to *reuse* aspects of a particular class in creating code that specializes and alters the functionality of that class. A compromise between encapsulation and flexibility is found by using *inheritance* in an object system. Inheritance is used to allow a *subclass* to specialize the functionality of it's *parent class* (aka, the *superclass*): (send Class :NEW '(<ivar0> ... <ivarN>) '(<cvar0> ... <cvarM>) <superclass>) (<ivar0> ... <ivarN>) is a list of new instance variables in the subclass; (<cvar0> ... <cvarN>) is a list of new class variables in the subclass; <superclass> is a class instance representing the parent from which the new subclass inherits variables and methods. "Inheritance" is occurring because all the instance variables of all the parent classes of the new subclass become the variables of each subclass instance. Furthermore, all methods defined on a parent class may also be used on a subclass instance. Note that while a subclass' methods can access the variables defined on the parent classes, the reverse isn't true. ** Object initialization. As mentioned earlier, new object instances are created by sending the message :NEW to a class object. Sending the message :NEW to a class automatically sends message :ISNEW to the newly created instance. By default :ISNEW on an instance is a no-op method defined on class 'Object', which is the implicit [(grand)*]parent of all instances. If you want to initialize the instance/class variables of a particular class, you must define an :ISNEW method on the class. Any parameters originally sent to the :NEW method will be passed on to the :ISNEW method and may be used to initialize an object to outside-world parameters. ** Example of using OOP features of XLISP with Motif widgets: The current implementation of the Motif widget class xmListWidgetClass makes it less-than-straightforward to create "browsers" of dynamic information. The problem is that a "browser" is a kind of application that lends itself to object oriented techniques that are not always straightforward to support in C. One often has a collection of 'things' that one wants to display in a 'list' and perform actions on the 'thing' corresponding to the visual selection of an element in the displayed list. xmListWidgetClass will display an array of XmStrings in a list. When one or more elements in the list are selected, XmStrings corresponding to the selected elements are returned. Since the XmStrings you put into the list widget are not the XmStrings you get out, you must call XmStringCompare on each element of the collection of 'things' to find out which 'thing' was selected. Presumably, you'll want to do more than just get back an XmString... normally one will want to access data structures associated with the 'thing' so as to perform an action dependent on those structures. This could be done with a lookup table, but there's also a better way... WINTERP allows us to subclass the Motif list widget so as to make it have the kind of functionality we want. This subclass will contain an additional instance variable 'items' which is an array of arbitrary XLISP objects to be displayed in a textual browser made from the list widget. These objects can have completely different internal representations -- the only requirement is that they follow the protocol of being able to respond to the messages :DISPLAY_STRING and :DEFAULT_ACTION. :DISPLAY_STRING returns a string representation of the object to be displayed in the browser. :DEFAULT_ACTION is the action to be performed when a list item is browsed (by double clicking on the item). The following creates the subclass <List_Browser> from superclass <XM_LIST_WIDGET_CLASS>: (setq List_Browser (send Class :NEW ;create a class inst '(items) ;new instance vars '() ;no class vars XM_LIST_WIDGET_CLASS)) ;superclass So now all instances of <List_Browser> will contain an instance variable <items> and will respond to all the messages understood by the XM_LIST_WIDGET_CLASS. We want our list browser to behave as described above, so we define an :ISNEW method to initialize instance variable <items> to the list of arbitrary objects to be displayed. <items> gets initialized to an array of objects, the list widget is created, and a XmNdefaultActionCallback is setup so that a double click will send the message :DEFAULT_ACTION to the browsed item: ;; (send List_Browser :new <items_list> <args-for-the-list-widget>) ;; <items_list> is a list of BROWSER_OBJECTs as described above. ;; <args-for-the-list-widget> -- these are the arguments that ;; will be passed on to the list widget ;; (send List_Browser :answer :isnew '(items_list &rest args) '( (let* ( (items_end_idx (length items_list)) (display_items (make-array items_end_idx))) ;; initialize the 'items' instance variable so that it ;; holds all the BROWSER_OBJECTs passed in <items_list> (setq items (make-array items_end_idx)) ;create the array (do ( ;copy elts from list to array (i 0 (1+ i)) (elts items_list (cdr elts))) ;; loop till no more elts ((null elts)) ;; loop body (setf (aref items i) (car elts)) (setf (aref display_items i) (send (car elts) :display_string)) ) ;; initialize the widget, passing in the browser items. (apply 'send-super `(:isnew ,@args :xmn_selection_policy :browse_select :xmn_items ,display_items :xmn_item_count ,items_end_idx )) ) ;; set up a callback on the list widget initialized above such ;; that a double click on the browser-item will send the ;; message :default_action to the BROWSER_OBJECT. (send-super :add_callback :xmn_default_action_callback '(callback_item_position) '((send (aref items (1- callback_item_position)) :default_action)) ) ) ) In the above code, SEND-SUPER works just like send, except that it doesn't require you to give it the object to send the message to. Instead, it implicitly assumes that it will be called from within a method, and will automatically send the message to a superclass of the object's class. The (apply 'send-super ...) form is actually calling the :ISNEW (instance initializer) method on XM_LIST_WIDGET_CLASS, which actually creates the widget via XmCreateList() or XmCreateScrolledList(). The APPLY '`' (BACKQUOTE) and '&rest args' (LAMBDA LIST) features of Lisp allow us to splice in the argument list passed to the instance of List_Browser into the function that actually creates the widget. Finally, method :ADD_CALLBACK is the WINTERP equivalent of XtAddCallback(). See the documentation on methods on WIDGET_CLASS for more details. The Motif List widget also defines a number of "methods" implemented as C routines such as XmListAddItem(), XmListAddItemUnselected(), XmListDeleteItem(), and XmListDeletePos(). In WINTERP, we define these as methods :ADD_ITEM, :ADD_ITEM_UNSELECTED, :DELETE_ITEM, and :DELETE_POS respectively. Since these methods modify the collection of objects represented by the list widget, we must update the internal array of objects <items> to correspond with the items displayed. We do this by intercepting those messages to the superclass of class <List_Browser> and handle them in <List_Browser> so as to update the appropriate data: (send List_Browser :answer :ADD_ITEM '(item position) '( (setq items (array-insert-pos items (1- position) item)) (send-super :add_item (send item :display_string) position) ) ) (send List_Browser :answer :ADD_ITEM_UNSELECTED '(item position) '( (setq items (array-insert-pos items (1- position) item)) (send-super :add_item_unselected (send item :display_string) position) ) ) (send List_Browser :answer :DELETE_ITEM '(item) '( ;; this is too lame to implement... requires that we compare ;; item with the result of :display_string done on every elt ;; of ivar 'items' (error "Message :DELETE_ITEM not supported in List_Browser") ) ) (send List_Browser :answer :DELETE_POS '(position) '( (setq items (array-delete-pos items (1- position))) (send-super :delete_pos position) ) ) To see how this subclassed list browser is used, and also to see how one might write a sample application in WINTERP using the object oriented features of XLISP, see ./../examples/grep-br.lsp. That file implements a simple search browser based on the UN*X command 'grep'. See also ./../examples/mail-br.lsp to see how you can build a simple mh-based mail browser. Finally, as another example of subclassing Motif widgets, see ./../examples/radiobox2.lsp. ============================================================================== * Running WINTERP: WINTERP can run as a stand-alone application which loads one or more Winterp-Lisp files upon startup -- these files create the user interface and describe the programmatic actions to be carried out by the user interface. When prototyping an application in WINTERP, interactive changes to the user-interface or application code can be effected by sending lisp code to WINTERP's eval-server. The program 'wl' is the client for the eval-server. The WINTERP gnuemacs editor interface (../src-client/winterp.el) provides a higher level interface to WINTERP's language evaluator. The Winterp-Lisp file ../examples/w_ctrlpnl.lsp provides a Motif interface for programming WINTERP. Due to portability problems with calling XtAppAddInput() on a buffered file such as stdin (the UN*X standard input), WINTERP cannot take its input directly from the "tty" or terminal emulator -- you must use the client program 'wl' for inputing Lisp into WINTERP. The WINTERP client program 'wl' (stands for Winterp Lisp) sends the XLISP expression given on it's command line to the WINTERP server (a Unix Domain socket, by default; TCP/IP sockets are optionally available as well). A higher level interface is provided in the form of a Gnu-Emacs extension: at the touch of a button, the expression currently being edited is sent to WINTERP for evaluation. The Winterp-Lisp file ./../examples/w_ctrlpnl.lsp provides a simple control panel for WINTERP which allows control of the interpreter's debugger, as well as a file browser allowing selection of files to be loaded or edited. The editor in the controlpanel provides a rudimentary means of interacting with Winterp's XLISP evaluator; while this is nowhere near as elegant as using the Gnu-Emacs interface, it provides a reasonable way-out for non Emacs-literate folks. Note however that I've spent a minimum of time on the editor interface in the control panel -- I can't justify spending time on such an interface when almost everybody using WINTERP in my lab (HPL's Software and Systems Lab) knows emacs. (I will gladly accept submitted improvements on the editor in ./../examples/w_ctrlpnl.lsp from those that make use of it.) Since an interactive session with WINTERP will print useful information on it's standard output and standard error streams, it is best to run the 'winterp' program in a terminal emulator window provided by 'xterm' (HPUX users may prefer 'hpterm'). Alternately, gnu-emacs users may find it more convenient to run 'winterp' in a shell process under emacs -- you may start a shell process by using the emacs command M-X shell. ** Unix Domain Socket vs. TCP/IP socket: WINTERP has a number of compilation and run-time options configuring how the eval-server is set up. The default compilation of WINTERP enables only a Unix Domain Socket -- the socket is created at startup by default. The Unix Domain Socket can be disabled via an X resource (see "WINTERP Resources" below), and can be enabled/disabled via a command-line argument (see "WINTERP -- the WINTERP Lisp server" below). Note that the Unix Domain Socket eval-server's client program is 'wl'. One may enable the TCP/IP socket capability by recompiling WINTERP with the line "#define WINTERP_WANT_INET_SERVER" added to ../src-server/config.h. Even when WINTERP is compiled with this option, the TCP/IP socket will not be enabled by default. This socket may be enabled via a command line option or an X resource. Note that the TCP/IP client program, 'wl-tcpip', is not compiled by default because WINTERP doesn't need it. The reason for disabling the TCP/IP socket is due to reasons of security. If you run WINTERP on a known port number, without any security precautions (see inetd.sec(4)), you are giving people open access to your account -- for example, others users will be able to execute programs on your account through the SYSTEM and POPEN primitives. By default, the program 'wl-tcpip' attempts to connect to the WINTERP server through your machine's loopback address, which it assumes is 127.0.0.1. If that is not your loopback address (isn't that IP address standard??), then you may have to specify 'localhost' or the hostname of your machine. 'wl-tcpip' will be able to connect to the WINTERP server more quickly if it can get an IP address without having to do a gethostbyname(). That's why I hardcoded the loopback address into wl-tcpip.c... (If this lookup is too slow, and you are running 'winterp' and 'wl-tcpip' locally, you may prefer using the Unix Domain Socket server mentioned below.) In contrast to the TCP/IP socket, the Unix Domain Socket is secure for single-user workstations. Since the Unix domain Socket is a Un*x file, security on multi-user machines is achieved via traditional file-protection techniques -- make the file unreadable/unwritable by others. To do this, you may change the name/location of the Unix Domain socket file via an environment variable, X resource, or command-line argument. A delivered application which doesn't need to talk to other programs may just load it's initialization file and not create any server socket at all. If WINTERP is compiled with both server options enabled, then one can run WINTERP with both a TCP/IP and Unix domain socket. If for some reason your machine or OS does not support Unix Domain Sockets, you may turn off compilation of these features. Do this by commenting out "#define WINTERP_WANT_UNIX_SERVER" in ../src-server/config.h and recompiling ../src-server/. ** WINTERP Resources (~/.Xdefaults): WINTERP is a standard Xtoolkit program. Any widgets you create will be affected by resource-manager settings just like they would in a normal program. In addition to resources for individual widgets, the following set up WINTERP's global application-resources. The default values are listed inside '[' and ']'. Winterp.lispInitFile: [initialize.lsp] By default, `pwd`/"initialize.lsp" is the XLISP initialization file that WINTERP attempts to load when it starts up. I strongly suggest that you set this resource to point to a file that is a copy of ./../examples/initialize.lsp". "initialize.lsp" contains some important macros and default settings for making WINTERP and XLISP run correctly. I suggest doing the following: copy ./../examples/initialize.lsp to <homedir>/.winterp, and set resource "Winterp.lispInitFile: <homedir>/.winterp". From there, you should customize .winterp so that XLISP and WINTERP work like you want them to. There are a number of global variables described in xlisp.doc which you may set to alter XLISP's behavior. See commented out sections in initialize.lsp for WINTERP customizations. One interesting customization you may want to make is to load ./../examples/w_ctrlpnl.lsp" out of your WINTERP initialization file. This will provide WINTERP with a rudimentary "control panel" allowing you to directly turn on/off the debugger, toggle output of backtraces on errors, maneuver between debug levels. The controlpanel also provides a file-selection-box widget for browsing and loading winterp-lisp files, and an editor for editing and evaluating code. Note: For delivering applications that know how to load their own lisp files, I suggest writing a script that does whatever you need it to and then executes "winterp -class <Application>". The command line argument -class causes WINTERP to use application-default file /usr/lib/X11/app-defaults/<Application>. That file in turn contains any resources needed by <Application>, with the resource Winterp.lispInitFile set to <Application>'s initialization file. That file in turn loads the application itself. Winterp.lispLibDir: [./] This resource sets the path to the default directory used by the LOAD primitive. If you give an unqualified filename <file> to LOAD, it will attempt to load <lispLibDir>/<file>.lsp . By default, this directory is WINTERP's current working directory `pwd`. I suggest that you set this resource to "<path>/winterp/examples/" , where <path> is the fully qualified pathname to the WINTERP distribution files. Winterp.lispTranscriptFile: [<none>] If you set this, XLISP will use the DRIBBLE primitive to write out a transcript of your interactions with the Lisp interpreter. By default, this is not done. Winterp.enableInitMsgs: [true] By default, this resource is set to "true", causing WINTERP to send its initialization messages to the standard output. WINTERP-based applications may want to put an application specific initialization message; for such cases WINTERP's initialization messages may be disabled by setting this resource to "false". Winterp.enableXtErrorBreak: [true] By default, WINTERP will signal an XLISP break when the Xtoolkit signals an error (via XtError()). When this resource is "true", Xtoolkit errors will print an error message and signal a Lisp error -- the Lisp call-sequence (or callback) that caused the error will terminate, however WINTERP will be able to execute other callbacks, input from the XLISP eval-server, etc. Setting the resource to "false" will cause WINTERP not to signal an XLISP break when the Xtoolkit signals an error (via XtError()); when this argument is specified, Xtoolkit errors will print an error message on stderr and cause WINTERP to exit. Winterp.enableXtWarningBreak: [false] By default, this resource is "FALSE", meaning that WINTERP will not signal an XLISP break when the Xtoolkit gives a warning (via XtWarning()) -- the error message will appear on stderr and execution will continue. When this resource is "TRUE", Xtoolkit warnings will print an error message and signal a Lisp error -- the Lisp call-sequence (or callback) that caused the warning will terminate, however WINTERP will be able to execute other callbacks, input from the XLISP eval-server, etc. Note that I've seen problems when setting enableXtWarningBreak: TRUE, thus the default value of FALSE. This is done because some XtWarnings were not meant to be broken out-of and can leave Motif in a weird state, causing possible subsequent strange behavior, core-dumps, etc. An example of this problem is associated with a Motif 1.1 popup menu bug. When a shell associated with a popup menu is destroyed, the following spurious warning is printed error: X Toolkit Warning: Attempt to remove non-existant passive grab When enableXtWarningBreak is set to TRUE, and the above warning occurs, subsequent attempts to close a window through the window manager will result in the error: XIO: fatal IO error 32 (Broken pipe) on X server... Winterp.enableXErrorBreak: [true] By default, WINTERP will signal an an XLISP break when the X server or X library signals an error (via XError()). When this resource is "true", X errors will print an error message and signal a Lisp error -- the Lisp call-sequence (or callback) that caused the error will terminate, however WINTERP will be able to execute other callbacks, input from the XLISP eval-server, etc. Setting the resource to "false" will cause WINTERP not to signal an XLISP break when the X library/server signals an error (via XError()); when this argument is specified, X errors will print an error message on stderr and cause WINTERP to exit. Winterp.enableUnixServer: [true] By default, this resource is set to "true", meaning that WINTERP will set up a Unix Domain Socket for input to WINTERP's eval-server. Setting this resource to "false" will disable the eval-server. Note that this resource is only available on WINTERPs compiled with "#define WINTERP_WANT_UNIX_SERVER" in file "./../src-server/config.h" Winterp.unixSocketFilepath: [/tmp/.winterp_serv] This resource sets the pathname for the Unix Domain Socket eval-server. By default, ".unixSocketFilepath" is "/tmp/.winterp_serv", you may want to specify a different ".unixSocketFilepath" if multiple 'winterp' applications are running. Alternately, you may want to hide the Unix Domain Socket from other users if you are on a multi-user machine. Note that specifying environment variable WINTERP_UNIX_SOCKET_FILEPATH overrides ".unixSocketFilepath". Note that this resource is only available on WINTERPs compiled with "#define WINTERP_WANT_UNIX_SERVER" in file "./../src-server/config.h" -- WINTERP_WANT_UNIX_SERVER is defined by default in WINTERP. Winterp.enableInetServer: [false] By default, this resource is set to "false", meaning that WINTERP will not set up a TCP/IP socket for input to WINTERP's eval-server. Setting this resource to "true" will enable the TCP/IP eval-server. Note that this resource is only available on WINTERPs compiled with "#define WINTERP_WANT_INET_SERVER" in file "./../src-server/config.h" Winterp.servicePort: [23751] 23751 is the default port number of the TCP/IP server. If you change this, you'll also have to change the port number that the winterp client 'wl-tcp' uses to connect with WINTERP -- see the '-p' option of 'wl-tcpip'. Resource ".servicePort" in 'winterp' as well as the service-port used by 'wl-tcpip' may be set via environment variable WINTERP_INET_PORTNUM. Note that this resource is only available on WINTERPs compiled with "#define WINTERP_WANT_INET_SERVER" in file "./../src-server/config.h" Winterp.serviceName: [widget_interp] "widget_interp" is the default service name for WINTERP's TCP/IP server if ".servicePort" is set to 0. This resource specifies the service name used by the TCP/IP server. Note that this resource is only available on WINTERPs compiled with "#define WINTERP_WANT_INET_SERVER" in file "./../src-server/config.h" ** Usage: The WINTERP Lisp server (./../src-server/winterp): Calling the following program-name and arguments will invoke the WINTERP program itself and set up the eval-server: usage: winterp [-class <classname>] [-init_file <file.lsp>] [-lib_dir <path-to-load-dir>] [-transcript_file <file.out>] [-no_init_msgs] [-enable_init_msgs] [-no_xterr_brk] [-enable_xterr_brk] [-no_xtwarn_brk] [-enable_xtwarn_brk] [-no_xerr_brk] [-enable_xerr_brk] [... Xtoolkit options ...] #ifdef WINTERP_WANT_INET_SERVER [-serv_port <portnum>] [-serv_name <servname>] [-no_inet_server] [-enable_inet_server] #endif /* WINTERP_WANT_INET_SERVER */ #ifdef WINTERP_WANT_UNIX_SERVER [-no_unix_server] [-enable_unix_server] [-unix_socket_file <socket-filepath>] #endif /* WINTERP_WANT_UNIX_SERVER */ NOTE: the #ifdef/#endif bracketed portions above refer to options that are optionally built-in when WINTERP is compiled. By default, the WINTERP_WANT_INET_SERVER portions are not compiled in with WINTERP, but the WINTERP_WANT_UNIX_SERVER are. This is explained in more detail above in the section "WINTERP Resources (~/.Xdefaults)" above. [-class <classname>]: this optional argument pair must occur first in the list of command-line arguments. This argument pair tells winterp the name of the application defaults file to use (e.g. /usr/lib/X11/app-defaults/<Classname>, and also sets the default class for all WINTERP top level shells. Note that <classname> should begin with a capital letter. If no [-class <classname>] parameter is given, the application 'winterp' will default to class "Winterp" and will look for an application-default file in /usr/lib/X11/app-defaults/Winterp. [... Xtoolkit options ...]: 'winterp' works just like a standard Xtoolkit/Motif application, and handles all the command line options allowed by the Xtoolkit, e.g. -bg, -fg, -font -display, -geometry, -iconic, -title, -name, -xrm, etc... For more information on these options, see the X11r4 document "X Toolkit Intrinsics -- C Language Interface" chapter 2.3 "Parsing the Command Line". Alternately, see the appropriate watered down documentation provided in the Motif users guide. [-init_file <file.lsp>]: this optional argument tells WINTERP to load the Winterp-Lisp file <file.lsp> upon startup. Setting this argument pair does the same thing as supplying the resource "Winterp.lispInitFile: <file.lsp>" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-lib_dir <path-to-load-dir>]: this optional argument pair sets the default path used by the Xlisp LOAD primitive for loading files that are not qualified by a directory path. Setting this argument pair does the same thing as supplying the resource "Winterp.lispLibDir: <path-to-load-dir>" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-transcript_file <file.out>]: this optional argument sets the file used by the Xlisp DRIBBLE primitive. Setting this argument pair does the same thing as supplying the resource "Winterp.lispTranscriptFile: <file.out>" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-no_init_msgs]: specifying this argument prevents WINTERP from printing initialization messages to the standard output. Setting this argument does the same thing as supplying the resource "Winterp.enableInitMsgs: false" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-enable_init_msgs]: specifying this argument enables printing of initialization messages from WINTERP -- this is enabled by default. Setting this argument does the same thing as supplying the resource "Winterp.enableInitMsgs: true" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-no_xterr_brk]: specifying this argument will cause WINTERP not to call an XLISP break when the Xtoolkit signals an error (via XtError()); when this argument is specified, Xtoolkit errors will print an error message on stderr and cause WINTERP to exit. Setting this argument does the same thing as supplying the resource "Winterp.enableXtErrorBreak: false" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-enable_xterr_brk]: specifying this argument will cause WINTERP to call an XLISP break when the Xtoolkit signals an error (via XtError()) -- this is enabled by default. When this argument is specified, Xtoolkit errors will print an error message and signal a Lisp error -- the Lisp call-sequence (or callback) that caused the error will terminate, however WINTERP will be able to execute other callbacks, input from the XLISP eval-server, etc. Setting this argument does the same thing as supplying the resource "Winterp.enableXtErrorBreak: true" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-no_xtwarn_brk]: specifying this argument will cause WINTERP not to call an XLISP break when the Xtoolkit gives a warning (via XtWarning()); when this argument is specified, Xtoolkit warnings will print an error message on stderr and continue executing. Setting this argument does the same thing as supplying the resource "Winterp.enableXtWarningBreak: false" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-enable_xtwarn_brk]: specifying this argument will cause WINTERP to call an XLISP break when the Xtoolkit gives a warning (via XtWarning()) -- this is enabled by default. When this argument is specified, Xtoolkit warnings will print an error message and signal a Lisp error -- the Lisp call-sequence (or callback) that caused the error will terminate, however WINTERP will be able to execute other callbacks, input from the XLISP eval-server, etc. Setting this argument does the same thing as supplying the resource "Winterp.enableXtWarningBreak: true" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-no_xerr_brk]: specifying this argument will cause WINTERP not to call an XLISP break when the X library/server signals an error (via XError()); when this argument is specified, X errors will print an error message on stderr and cause WINTERP to exit. Setting this argument does the same thing as supplying the resource "Winterp.enableXErrorBreak: false" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-enable_xerr_brk]: specifying this argument will cause WINTERP to call an XLISP break when the X signals an error (via XError()) -- this is enabled by default. When this argument is specified, X errors will print an error message and signal a Lisp error -- the Lisp call-sequence (or callback) that caused the error will terminate, however WINTERP will be able to execute other callbacks, input from the XLISP eval-server, etc. Setting this argument does the same thing as supplying the resource "Winterp.enableXErrorBreak: true" (see "WINTERP Resources (~/.Xdefaults)" above for details). NOTE: The following command line options are only available if WINTERP was compiled with "#define WINTERP_WANT_UNIX_SERVER" in file "./../src-server/config.h". By default, WINTERP compiles with the Unix Domain Socket server enabled, so these arguments will be available in the default WINTERP. [-no_unix_server]: specifying this argument disables WINTERP's Unix Domain Socket eval-server. Setting this argument does the same thing as supplying the resource "Winterp.enableUnixServer: false" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-enable_unix_server]: specifying this argument enables WINTERP's Unix Domain Socket eval-server -- this is the default. Setting this argument does the same thing as supplying the resource "Winterp.enableUnixServer: true" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-unix_socket_file <socket-filepath>]: specifying this argument pair sets the Unix Domain Socket specified by <socket-filepath>. By default, <socket-filepath> is "/tmp/.winterp_serv", you may want to specify a different <socket-filepath> if multiple 'winterp' applications are running. Alternately, you may want to hide the Unix Domain Socket from other users if you are on a multi-user machine. Setting this argument does the same thing as supplying the resource "Winterp.unixSocketFilepath: <socket-filepath>" (see "WINTERP Resources (~/.Xdefaults)" above for details). Note that specifying environment variable WINTERP_UNIX_SOCKET_FILEPATH overrides this command line argument (as well as resource ".unixSocketFilepath"). NOTE: The following command line options are only available if WINTERP was compiled with "#define WINTERP_WANT_INET_SERVER" in file "./../src-server/config.h". By default WINTERP does not compile with the TCP/IP server capabilities because they are a potential security hole. [-no_inet_server]: specifying this argument disables WINTERP's TCP/IP eval-server -- this is the default. Setting this argument does the same thing as supplying the resource "Winterp.enableInetServer: false" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-enable_inet_server]: specifying this argument enables WINTERP's TCP/IP eval-server. Setting this argument does the same thing as supplying the resource "Winterp.enableInetServer: true" (see "WINTERP Resources (~/.Xdefaults)" above for details). [-serv_port <portnum>]: setting this optional argument pair does the same thing as supplying the resource "Winterp.servicePort: <portnum>" (see "WINTERP Resources (~/.Xdefaults)" above). Note that specifying environment variable WINTERP_INET_PORTNUM overrides this command line argument (as well as resource ".servicePort"). [-serv_name <servname>]: setting this optional argument pair does the same thing as supplying the resource "Winterp.serviceName: <portnum>" (see "WINTERP Resources (~/.Xdefaults)" above). ** Usage: the WINTERP-Lisp Unix Domain Socket client (./../src-client/wl): usage: wl [-f <socket-filepath>] [<s-expr>] The optional <socket-filepath> argument sets the pathname for the Unix Domain Socket eval-server. By default, <socket-filepath> is "/tmp/.winterp_serv", you may want to specify a different <socket-filepath> if multiple 'winterp' applications are running. Alternately, you may want to hide the Unix Domain Socket from other users if you are on a multi-user machine. Note that you may specify <socket-filepath> via environment variable WINTERP_UNIX_SOCKET_FILEPATH. The environment variable sets <socket-filepath> for both 'wl' and 'winterp'. The <s-expr> argument is a single Lisp s-expression to be sent to WINTERP's Lisp listener. If no <s-expr> argument is given, 'wl' sends an EOF (==^D) to XLISP, indicating that XLISP should exit the current level -- if XLISP is in a "breakloop" due to a Lisp error, this will exist the current "breaklevel". If XLISP isn't in a "breakloop", then omitting the <s-expr> will quit XLISP and cause WINTERP to exit. Note that the <s-expr> must be quoted with ['] so that the shell does not attempt to interpret the parentheses as shell commands. ** Usage: the WINTERP-Lisp TCP/IP client (./../src-client/wl-tcpip): usage: wl-tcpip [-h <hostname>] [-p <port>] [<s-expr>] The optional <hostname> argument allows you to specify the host upon which the WINTERP's eval-server is running. By default, 'wl-tcpip' attempts to connect to a WINTERP server running at IP address 127.0.0.1. See the note below for further details. The hostname may also be specified by setting environment variable WINTERP_INET_HOSTNAME. The optional <port> argument specifies a different port number for WINTERP's eval-server. The default is 23751; you may want to change the default (along with WINTERP's "Winterp.servicePort" resource) if 23751 is already defined in /etc/services. You will also need to change <port> if you are running multiple instances of WINTERP on the same machine. You may set the <port> argument as well as WINTERP's ".servicePort" by setting environment variable WINTERP_INET_PORTNUM to the desired port number. The <s-expr> argument is a single Lisp s-expression to be sent to WINTERP's Lisp listener. If no <s-expr> argument is given, 'wl-tcpip' sends an EOF (==^D) to XLISP, indicating that XLISP should exit the current level -- if XLISP is in a "breakloop" due to a Lisp error, this will exist the current "breaklevel". If XLISP isn't in a "breakloop", then omitting the <s-expr> will quit XLISP and cause WINTERP to exit. Note that the <s-expr> must be quoted with ['] so that the shell does not attempt to interpret the parentheses as shell commands. NOTE-0: 'wl-tcpip' is not compiled in the WINTERP distribution by default -- do "cc -O -o wl-tcpip wl-tcpip.c" to compile it. Likewise, the 'winterp' binary itself does not compile with the TCP/IP server feature. To get the TCP/IP server, you must recompile WINTERP after setting "#define WINTERP_WANT_INET_SERVER" in ./../src-server/config.h; after recompilation run 'winterp' with the resource "Winterp.enableInetServer: true". NOTE-1: By default, 'wl-tcpip' uses the IP address 127.0.0.1 as the hostname. This is the standard "loopback" or localhost address on all UN*X machines I've worked with. If your setup defines hostname "localhost" as a different I.P. address, you may need to specify 'localhost' or `hostname` as <hostname>. You may see significant speed increases in 'wl-tcpip' by replacing "127.0.0.1" in ./../src-server/config.h with the appropriate IP address and recompiling 'wl-tcpip.c' -- hostname lookup on some machines can be slow. If you are really concerned about the speed of making local connections, between 'winterp' and 'wl-tcpip', you should consider using 'wl' as described above. ** Usage: the Gnu-Emacs programmers interface (./../src-client/winterp.el): The gnuemacs interface to WINTERP makes the following assumptions: (1) You're using GNUEMACS version 18.54 or later (I've used winterp.el with versions of gnuemacs as old as 18.44, but you may need to load a >18.54 version of lisp/shell.el). (2) You've installed the WINTERP-Lisp client program 'wl' somewhere on your UX*X search path (see $PATH). (3) The WINTERP-server is running and sending stderr and stdout to a reasonable place such as a terminal emulator. To use WINTERP's GNUEMACS interface, you must first load the file ./../src-client/winterp.el into gnuemacs. You may do this manually by using the command 'M-X load-file<return>' specifying the file 'winterp.el' with the appropriate path information prepended. Alternately, you may include the form '(load "<path>winterp")' in your $HOME/.emacs file, where <path> is the appropriate path to the file ./../src-client/winterp.el. Once winterp.el is loaded, you should visit a WINTERP-Lisp file using GNUEMACS command 'M-X find-file<return>' (C-x C-f). A file with suffix '.lsp' denotes an XLISP or WINTERP-Lisp file, and these will automatically put the associated editor buffer "Lisp mode" -- the GNUEMACS mode line will indicate the mode as '(Lisp)'. Within a Lisp-mode buffer, the following additional commands and keybindings are defined: winterp-send-defun (C-M-X): The Lisp s-expression at the "point" (cursor) is sent to the WINTERP-server for evaluation. winterp-send-buffer: The current buffer is sent to the WINTERP-server for evaluation. winterp-send-exit: (C-c C-d): Sends a ^D == EOF to XLISP, which exists the current breaklevel. If XLISP is not at a breaklevel, then this command will exit XLISP and cause the WINTERP-server to terminate. Additional commands that are useful in GNUEMACS' Lisp-mode: indent-sexp (C-M-Q): Formats and indents the s-expression under the "point" (cursor). indent-for-comment (M-;): Will place a Lisp comment character at the appropriate column in your Lisp-source. If a comment already exists on the current line, this will reindent the comment. forward-list: (C-M-N): Moves the "point" forward across a balanced group of parentheses. This is useful for moving the cursor to the next form. backward-list: (C-M-P): Moves the "point" backward across a balanced group of parentheses. This is useful for moving the cursor to the previous form. forward-sexp: (C-M-F): Moves the "point" forward across one balanced expression. backward-sexp (C-M-B): Moves the "point" backward across one balanced expression. I have found it useful to bind commands backward-list, forward-list, and winterp-send-buffer to "function" keys F6, F7, and F8, respectively, because these commands are used often when using GNUEMACS to interface with WINTERP. DEBUGGING-TIP: If you are using WINTERP's GNUEMACS interface and functions such as winterp-send-defun are not working correctly, you should check the GNUEMACS buffer *winterp-client-shell* for error output from the program 'wl'. WINTERP's GNUEMACS interface requires that the winterp client program 'wl' works correctly -- see the documentation on 'wl' above for information. ============================================================================== * Winterp-Lisp global variables. WINTERP defines the following global variables: *XLISP_VERSION* -- this is set to a FIXNUM indicating the current version of XLISP used in WINTERP. For XLISP 2.1 *XLISP_VERSION* == 2. *XLISP_REVISION* -- this is set to a FIXNUM indicating the current revision of XLISP used in WINTERP. For XLISP 2.1 *XLISP_REVISION* == 1. *MOTIF_VERSION* -- this is set to a FIXNUM indicating the current version of Motif used by WINTERP. This is the value of XmVERSION in <Xm/Xm.h>. *MOTIF_REVISION* -- this is set to a FIXNUM indicating the current revision of Motif used by WINTERP. This is the value of XmREVISION in <Xm/Xm.h>. *WINTERP_VERSION* -- this is set to a FIXNUM indicating the current revision of WINTERP. For WINTERP 1.11 *WINTERP_VERSION* == 1. *WINTERP_REVISION* -- this is set to a FIXNUM indicating the current revision of WINTERP. For WINTERP 1.11 *WINTERP_REVISION* == 11. *TOPLEVEL_WIDGET* -- this is set to a WIDGETOBJ, the WINTERP application's application-shell widget. By default, this shell-widget is unmapped and not visible on the screen -- it is used internally to retrieve application-resources and certain default X values needed by WINTERP's internals. However, users may use this existing shell widget for whatever purpose they want. Note that Bug-Free operation of WINTERP is not at all guaranteed if you destroy this widget. Also, you'll want to use this widget to retrieve the command line arguments with which winterp was invoked. Do this with (send *TOPLEVEL_WIDGET* :GET_ARGV) *SAVED_OBJS* -- This is set to an ARRAY of WIDGETOBJ, CALLBACKOBJs, TIMEOUTOBJs. This is really used only for debugging purposes, as well as other hackery on WINTERP's internals. Bug-Free operation of WINTERP is not at all guaranteed if you mess with the values in this ARRAY. ============================================================================== * WINTERP <--> Motif Widget Classes ** WIDGET_CLASS -- the WINTERP widget metaclass. WIDGET_CLASS is not an instantiable class. It is the base class from which all WINTERP widget-classes inherit methods and functionality from. Note that some widget classes will override methods defined on WIDGET_CLASS. *** equivalent Xt 'WidgetClass': There is no direct equivalent. This class is essentially a combination of classes 'Primitive', 'Core', 'Manager' etc. *** equivalent creation convenience function: XtCreateWidget() -- see below. *** XtCreateWidget(): (send <WIDGET_CLASS> :new [:managed/:unmanaged] [<name>] <parent> [<resource_0> <value_0>] . . . [<resource_n> <value_n>]) --> returns a newly created WIDGETOBJ of class <WIDGET_CLASS>. <WIDGET_CLASS> is an XLISP class-object that has been previously been defined, either by compiling it into the C source, or by subclassing existing widgets, or by creating a new composite widget class made out of existing or subclassed widget classes. The optional keyword-argument :MANAGED will cause a subsequent call to XtManageChild() (see also method :MANAGE). If the submessage :UNMANAGED is present, or no submessage, then XtManageChild() won't be called, and the resulting widget will be returned unmanaged. The optional argument <name> is a string which becomes the name of the widget as used by the resource manager. If you are not setting any widget resources via the resource manager, you may leave this parameter out. The argument <parent> is a WIDGETOBJ that will be managing the widget to be created. The optional arguments [<resource_i> <value_i>]... represent a series of Motif resource name/value pairs -- upon creation of the widget, each <resource_i> will be set to <value_i>. Resource names are keyword symbols which are described in the "WINTERP <--> Motif resources" section of this document. Each <resource_i> expects a specific Lisp type for <value_i> and will signal an error if the wrong type <value_i> is given. For example, the Motif resource XmNx indicates the X-axis location of a widget with respect to it's parent -- the corresponding WINTERP-Lisp symbol :XMN_X will expect it's associated value to be a FIXNUM. Almost all resource values may also be specified as a STRING and Xt&Motif's resource converters will automatically convert the STRING to the appropriate type. The string values may be specified in the same way that you would specify a value for use by the X resource database (e.g. ~/.Xdefaults or /usr/lib/X11/app-defaults/*). Note that different resource names are valid for each particular widget class. See the Motif manual pages on a particular widget class to find out which resources may be set. If you attempt to set a resource that doesn't exist for a particular widget's class, no error will be signaled, and the invalid resource will be ignored. (I consider this behavior is a bug in the design of the Xt intrinsics whereas the X consortium considers this a "feature" of the implementation. WINTERP could ask the toolkit to see whether each specified resource is valid, but that would make execution too slow. Given that the X Consortium will never fix this bug, a future version of WINTERP may allow such checking to occur as an option). *** XtSetValues(): (send <widget> :SET_VALUES <resource_0> <value_0> . . . [<resource_n> <value_n>]) --> returns <widget>. This method allows you to set the value of widget resource <resource_i> to value <value_i> for the widget object <widget>. Resource names are keyword symbols which are described in the "WINTERP <--> Motif resources" section of this document. Each <resource_i> expects a specific Lisp type for <value_i> and will signal an error if the wrong type <value_i> is given. For example, the Motif resource XmNx indicates the X-axis location of a widget with respect to it's parent -- the corresponding WINTERP-Lisp symbol :XMN_X will expect it's associated value to be a FIXNUM. Note that different resource names are valid for each particular widget class. See the Motif manual pages on a particular widget class to find out which resources may be set. If you attempt to set a resource that doesn't exist for a particular widget's class, no error will be signaled, and the invalid resource will be ignored. (I consider this behavior is a bug in the design of the Xt intrinsics whereas the X consortium considers this a "feature" of the implementation. WINTERP could ask the toolkit to see whether each specified resource is valid, but that would make execution too slow. Given that the X Consortium will never fix this bug, a future version of WINTERP may allow such checking to occur as an option). *** XtGetValues(): (send <widget> :GET_VALUES <resource_0> <place_0> . . . <resource_n> <place_n>) --> returns a list of values corresponding to <place_i>==NIL (see below). This method accesses values inside the OBJECT <widget> and stores them in Lisp data structures. <place_i> is a the place to put the value associated with widget resource name <resource_i>. Resource names are keyword symbols which are described in the "WINTERP <--> Motif resources" section of this document. If <place_i> is NIL, then <resource_i>'s value is returned by the method as an element in a list of results. If <place_i> is a quoted symbol, then that symbol gets bound to <resource_i>'s value. If <place_i> is a place-form (see documentation on xLisp's 'setf' construct) then <resource_i>'s value will be put in <place_i>, which is one of the following field specifiers: <sym> set value of a symbol (car <expr>) set car of a cons node (cdr <expr>) set cdr of a cons node (nth <n> <expr>) set nth car of a list (aref <expr> <n>) set nth element of an array (get <sym> <prop>) set value of a property (symbol-value <sym>) set value-cell of a symbol (symbol-function <sym>) set function-cell of a symbol (symbol-plist <sym>) set property list of a symbol Note that different resource names are valid for each particular widget class. See the Motif manual pages on a particular widget class to find out which resources may be retrieved. If you attempt to retrieve the value of a resource value that doesn't exist for a particular widget-class, an error will be signaled. *** XtAddCallback(): (send <widget_instance> :ADD_CALLBACK <name> <call_data_binding_names_list> <code>) --> returns: <callback_id_object> of type CALLBACKOBJ (send <widget_instance> :SET_CALLBACK <name> <call_data_binding_names_list> <code>) --> returns: <callback_id_object> of type CALLBACKOBJ Both these methods add the callback <name> to <widget_instance>. :SET_CALLBACK contains additional code to ensure that only one callback exists per <name>. :SET_CALLBACK is useful when one is prototyping an application and changing callbacks frequently -- you don't have to worry about removing the previous callback with XT_REMOVE_CALLBACK. Note that :ADD_CALLBACK should be used in time-sensitive code, since :SET_CALLBACK is slower. <name> is a resource keyword of type XmRCallback, eg, :XMN_ACTIVATE_CALLBACK, :XMN_ARM_CALLBACK, :XMN_DISARM_CALLBACK. For a list of valid resource names for callbacks, see the "XmRCallback" subheading of the "WINTERP <--> Motif resources" section of this document. Different widget classes support different callback names -- see the Motif manual page for the appropriate widget class to see which callbacks are valid for a particular widget class. Note that an error will be signaled if an invalid callback <name> is given. <call_data_binding_name_list> is a list of symbols that get bound to data specific to the action on the callback widget. Most widgets return call_data of type XmAnyCallbackStruct: typedef struct { int reason; Event *event; } XmAnyCallbackStruct; For such widgets, specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback The symbol CALLBACK_REASON is bound to one of the following symbols during the callback: CR_NONE, CR_HELP, CR_VALUE_CHANGED, CR_INCREMENT, CR_DECREMENT, CR_PAGE_INCREMENT, CR_PAGE_DECREMENT, CR_TO_TOP, CR_TO_BOTTOM, CR_DRAG, CR_ACTIVATE, CR_ARM, CR_DISARM, CR_MAP, CR_UNMAP, CR_FOCUS, CR_LOSING_FOCUS, CR_MODIFYING_TEXT_VALUE, CR_MOVING_INSERT_CURSOR, CR_EXECUTE, CR_SINGLE_SELECT, CR_MULTIPLE_SELECT, CR_EXTENDED_SELECT, CR_BROWSE_SELECT, CR_DEFAULT_ACTION, CR_CLIPBOARD_DATA_REQUEST, CR_CLIPBOARD_DATA_DELETE, CR_CASCADING, CR_OK, CR_CANCEL, CR_APPLY, CR_NO_MATCH, CR_COMMAND_ENTERED, CR_COMMAND_CHANGED, CR_EXPOSE, CR_RESIZE, CR_INPUT. #ifdef MOTIF_1.1 CR_GAIN_PRIMARY, CR_LOSE_PRIMARY. #endif /* MOTIF_1.1 */ Note that widget classes whose callback call_data isn't of type XmAnyCallbackStruct will override WIDGET_CLASS's :ADD_CALLBACK and :SET_CALLBACK methods and provide a class-specific method that allows retrieval of values from other kinds of Xm*CallbackStructs. These methods will allow additional symbols in <call_data_binding_names_list>. However, all :ADD_CALLBACK and :SET_CALLBACK methods allow for the symbols CALLBACK_WIDGET CALLBACK_REASON and CALLBACK_XEVENT. <code> is a list of Lisp expressions that are evaluated when the callback occurs. When the callback fires and <code> gets evaluated, the lexical environment that existed for the call to :ADD_CALLBACK/:SET_CALLBACK will be used for value and functional bindings. NOTE: The the callback associated with the returned <callback_id_object> may be removed via XtRemoveCallback() with the WINTERP primitive (XT_REMOVE_CALLBACK <callback_id_object>). *** XtRemoveAllCallbacks(): (SEND <widget> :REMOVE_ALL_CALLBACKS <name>) --> returns T. <name> is a resource keyword of type XmRCallback, eg, :XMN_ACTIVATE_CALLBACK, :XMN_ARM_CALLBACK, :XMN_DISARM_CALLBACK. This method removes all callbacks matching <name> from <widget>. WARNING: (from Motif 1.1 README file): Calling this routine from an application removes all callbacks from a widget, including those added internally by Motif code. An application should use XtRemoveCallback or XtRemoveCallbacks to remove particular callbacks. *** XtHasCallbacks(): (SEND <widget> :HAS_CALLBACKS <name>) --> returns CALLBACK_NO_LIST if callback <name> doesn't exist. --> returns CALLBACK_HAS_NONE if callback list has no callbacks. --> returns CALLBACK_HAS_SOME if some callbacks on list. <name> is a resource keyword of type XmRCallback, eg, :XMN_ACTIVATE_CALLBACK, :XMN_ARM_CALLBACK, :XMN_DISARM_CALLBACK, etc. *** XtAddEventHandler(), XtAddRawEventHandler(): (send <widget> :ADD_EVENT_HANDLER [:RAW] [:NONMASKABLE] <event_mask> <event_data_bindings_list> <code>) (send <widget> :SET_EVENT_HANDLER [:RAW] [:NONMASKABLE] <event_mask> <event_data_bindings_list> <code>) --> returns an <EVHANDLEROBJ> which identifies the handler. Optional keyword :RAW indicates that XtAddRawEventHandler() will be invoked so as to not affect the widget's input mask nor for it to select for events. Otherwise XtAddEventHandler() will get called. Optional keyword :NONMASKABLE indicates that the handler should be called for nonmaskable events. <event_mask> is a FIXNUM which is the value of the an event mask. event masks may be combined by doing a bitwise OR via the XLISP 'LOGIOR' function. The following event mask constants have been defined: NO_EVENT_MASK, KEY_PRESS_MASK, KEY_RELEASE_MASK, BUTTON_PRESS_MASK, BUTTON_RELEASE_MASK, ENTER_WINDOW_MASK, LEAVE_WINDOW_MASK, POINTER_MOTION_MASK, POINTER_MOTIONHINT_MASK, BUTTON1_MOTION_MASK, BUTTON2_MOTION_MASK, BUTTON3_MOTION_MASK, BUTTON4_MOTION_MASK, BUTTON5_MOTION_MASK, BUTTON_MOTION_MASK, KEYMAP_STATE_MASK, EXPOSURE_MASK, VISIBILITY_CHANGE_MASK STRUCTURE_NOTIFY_MASK, RESIZE_REDIRECT_MASK, SUBSTRUCTURE_NOTIFY_MASK SUBSTRUCTURE_REDIRECT_MASK, FOCUS_CHANGE_MASK, PROPERTY_CHANGE_MASK COLORMAP_CHANGE_MASK, OWNER_GRAB_BUTTON_MASK. <event_data_bindings_list> is a list of symbols that get bound to data specific to the action that caused the event handler to fire. These symbols get bound to specific values during the execution of the event-handler <code>. Valid symbols are: EVHANDLER_WIDGET -- bound to the WIDGETOBJ of the event EVHANDLER_XEVENT -- bound to the XEvent that fired handler. EVHANDLER_BUTTON -- fixnum -- the button or keycode EVHANDLER_TIME -- fixnum -- the timestamp. <code> is a list of Lisp-forms to be evaluated when the eventhandler fires. When the eventhandler fires, the lexical environment that existed for the call to :ADD_EVENT_HANDLER will be used for value and functional bindings. The eventhandler may be removed by giving the <EVHANDLEROBJ> to procedure REMOVE_EVENT_HANDLER. Note that the :SET_EVENT_HANDLER variant does exactly the same thing as :ADD_EVENT_HANDLER except that it ensures that only one event handler with the given <event_mask>, :RAW and :NONMASKABLE specifications exist on <widget>. It will remove all other matching event handlers in order to set the current event handler. This function is useful for making interactive changes to an event handler without having to remember to remove the previous handler. Note that :SET_EVENT_HANDLER is slower, so it should not be used in cases where speed is important. NOTE: the EVHANDLER_TIME and EVHANDLER_BUTTON binding values may return gibberish if the eventhandler returned a event->type that doesn't define those fields. This is currently just a kludge for Motif functions that require the event->button info (popup menus) or event->time info (XmClipboard*). Hopefully I'll come up with something better in the future... *** XtRemoveEventHandler() // XtRemoveRawEventHandler() (REMOVE_EVENT_HANDLER <EVHANDEROBJ>) --> returns true. This procedure removes the eventhandler corresponding to the <EVHANDLEROBJ> returned by method :ADD_EVENT_HANDLER *** XtBuildEventMask(): (send <widget> :BUILD_EVENT_MASK) --> returns as a FIXNUM the event mask representing the logical OR of all event masks for event handlers registered on <widget>. This includes masks set by XtAddEventHandler(), all event translations & accelerators. *** XtOverrideTranslations(): (send <widget> :OVERRIDE_TRANSLATIONS <translations>) --> returns <widget> This method destructively merges the new <translations> into <widget>'s existing translations -- event sequences in <translations> that already exist from a previous translation will override. <translations> can be a string, in which case it is compiled into a translation table. Otherwise, we expect a value of type XT_TRANSLATIONS as returned by XT_PARSE_TRANSLATION_TABLE. *** XtAugmentTranslations(): (send <widget> :AUGMENT_TRANSLATIONS <translations>) --> returns <widget>. This method nondestructively merges the new <translations> into <widget>'s existing translations -- event sequences in <translations> that already exist a previous translation will be ignored. <translations> can be a string, in which case it is compiled into a translation table. Otherwise, we expect a value of type XT_TRANSLATIONS as returned by XT_PARSE_TRANSLATION_TABLE. *** XtUninstallTranslations(): (send <widget> :UNINSTALL_TRANSLATIONS) --> returns <widget> This method removes all translations from <widget>. *** XtInstallAccelerators(): (send <destination> :INSTALL_ACCELERATORS <source>) --> returns <destination> This method installs the accelerators from widget <source> onto widget <destination> by augmenting the destination translations with the source accelerators. Both <source> and <destination> are WIDGETOBJs. *** XtInstallAllAccelerators(): (send <destination> :INSTALL_ALL_ACCELERATORS <source>) --> returns <destination> This method installs the accelerators from widget <source> and all it's children onto widget <destination> by augmenting the destination translations with the source accelerators. Both <source> and <destination> are WIDGETOBJs. *** XtDestroyWidget(): (send <widget> :DESTROY) --> returns NIL. After calling this routine, the WIDGETOBJ <widget> may be garbage collected, along with all other resources the widget references, such as PIXMAPs CALLBACKOBJs, and EVHANDLEROBJs. Furthermore, this will destroy all children of the destroyed widget and allow their storage to be garbage collected as well. *** XtManageChild(): (send <widget> :MANAGE) --> returns <widget> This method will add <widget> to it's parent-widget's managed list, which means it will become visible (if mapped) and will take up space within the managing widget. *** XtUnmanageChild(): (send <widget> :UNMANAGE) --> returns <widget> This method will remove <widget> from its parent's managed list, which means it will no longer be visible or take up space. *** XtAddGrab(): (send <widget> :ADD_GRAB <exclusive_p> <spring_loaded_p>) --> returns <widget> This method appends <widget> to the modal cascade -- redirects user input to this widget. <exclusive_p> and <spring_loaded_p> are booleans. *** XtRemoveGrab(): (send <widget> :REMOVE_GRAB) --> returns <widget> Removes the redirection of user input to <widget> done via :ADD_GRAB *** XtIsCompositeObject() [MOTIF_1.0] // XtIsComposite() [MOTIF_1.1]: (send <widget> :IS_COMPOSITE) --> returns T if <widget> is a composite widget, else NIL. *** XtIsConstraint(): (send <widget> :IS_CONSTRAINT) --> returns T if <widget> is a constraint widget, else NIL. *** XtIsShell(): (send <widget> :IS_SHELL) --> returns T if <widget> is a shell widget, else NIL. *** XtSetSensitive(): (send <widget> :SET_SENSITIVE <sensitive_p>) --> returns <widget>. If <sensitive_p> is NIL, then the widget will not respond to user input. *** XtSetMappedWhenManaged(): (send <widget> :SET_MAPPED_WHEN_MANAGED <mapped_p>) --> returns <widget>. If <mapped_p> is non-NIL, then the widget will be mapped (displayed) when it is managed by it's parent widget. *** XtIsManaged(): (send <widget> :IS_MANAGED) --> returns T if the widget is managed, else NIL. See also method :MANAGE and :UNMANAGE *** XtIsRealized(): (send <widget> :IS_REALIZED) --> returns T if the widget is realized, else NIL. See also methods :REALIZE and :UNREALIZE *** XtIsSensitive(): (send <widget> :IS_SENSITIVE) --> returns T if the widget will accept user input, else NIL. See also method :SET_SENSITIVE. *** XtParent(): (send <widget> :PARENT) --> returns the given <widget>'s parent widget or NIL if no parent. *** XtWindow() [MOTIF_1.0] // XtWindowOfObject() [MOTIF_1.1]: (send <widget> :WINDOW) --> returns the given <widget>'s window. *** XtMapWidget(): (send <widget> :MAP) --> returns <widget>. If the widget is realized and managed, this method will make the window appear on the display. Make it disappear with :UNMAP. *** XtUnmapWidget(): (send <widget> :UNMAP) --> returns <widget>. If the widget is realized and managed, this method will make the window disappear from the display. Make it reappear with :MAP. *** XmUpdateDisplay(): (send <widget> :UPDATE_DISPLAY) --> returns <widget>. This method is useful for refreshing WINTERP's Xwindows displays while inside a callback. Since the X display won't get refreshed until you hit the XtNextEvent/XtDispatcEvent loop you cannot normally change the display inside a callback. Thus, this function is especially useful for forcing a status message to be seen before a long computation occurs within a callback. *** XmAddTabGroup(): (send <widget> :ADD_TAB_GROUP) --> returns <widget> This method adds <widget> to the list of tab groups associated with a particular widget hierarchy. *** XmRemoveTabGroup(): (send <widget> :REMOVE_TAB_GROUP) --> returns <widget> This method removes <widget> from the list of tab groups associated with a particular widget hierarchy. *** XmIsPrimitive(): (send <widget> :IS_PRIMITIVE) --> returns T if <widget> is a motif primitive widget, else NIL. *** XmIsGadget(): (send <widget> :IS_GADGET) --> returns T if <widget> is a motif gadget, else NIL. *** XmIsManager(): (send <widget> :IS_MANAGER) --> returns T if <widget> is a motif manager widget, else NIL. #ifdef MOTIF_1.1 *** XmProcessTraversal() [Motif 1.1 only]: (send <widget> :PROCESS_TRAVERSAL <direction>) --> "Returns T if the setting succeeded. Returns NIL if the keyboard focus policy is not :EXPLICIT, if there are no traversable items, or if the call to the routine has invalid parameters." This method "determines which component receives keyboard events when a widget has the focus." (from XmProcessTraversal.3X manual page) <direction> is a keyword symbol, one of the following: :TRAVERSE_CURRENT "Finds the hierarchy and the tab group that contain widget. If this tab group is not the active tab group, makes it the active tab group. If widget is an item in the active tab group, makes it the active item. If widget is the active tab group, makes the first traversable item in the tab group the active item." :TRAVERSE_DOWN "Finds the hierarchy that contains widget. Finds the active item in the active tab group and makes the item below it the active item. If there is no item below, wraps." :TRAVERSE_HOME "Finds the hierarchy that contains widget. Finds the active item in the active tab group and makes the first traversable item in the tab group the active item." :TRAVERSE_LEFT "Finds the hierarchy that contains widget. Finds the active item in the active tab group and makes the item to the left the active item. If there is no item to the left, wraps." :TRAVERSE_NEXT "Finds the hierarchy that contains widget. Finds the active item in the active tab group and makes the next item the active item." :TRAVERSE_NEXT_TAB_GROUP "Finds the hierarchy that contains widget. Finds the active tab group (if any) and makes the next tab group the active tab group in the hierarchy." :TRAVERSE_PREV "Finds the hierarchy that contains widget. Finds the active item in the active tab group and makes the previous item the active item." :TRAVERSE_PREV_TAB_GROUP "Finds the hierarchy that contains widget. Finds the active tab group (if any) and makes the previous tab group the active tab group in the hierarchy. :TRAVERSE_RIGHT "Finds the hierarchy that contains widget. Finds the active item in the active tab group and makes the item to the right the active item. If there is no item to the right, wraps." :TRAVERSE_UP "Finds the hierarchy that contains widget. Finds the active item in the active tab group and makes the item above it the active item. If there is no item above, wraps." #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XtName() [Motif 1.1 only]: (send <widget> :NAME) --> returns STRING of widget's name. The name returned is the STRING passed to the optional [<name>] argument during widget creation. If no <name> argument is given at widget creation time, the result of method :NAME will be the empty string "". See method :NEW on WIDGET_CLASS for details. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XtCallActionProc() [Motif 1.1 only]: (send <widget> :CALL_ACTION_PROC <action> <xevent> [<param0> [<param1> [...] ]]) --> Returns <widget>. This method invokes the specified action procedure <action> on <widget>. <action> is a STRING specifying the name of the action procedure defined on the widget. See the manual page on the widget's class to find out the defined names for widget action procedures. Note that the action procedure names are case sensitive. If the action procedure is not found, an XtWarning is generated. <xevent> is an XEVENT object that is passed on to the action procedure. Typically, this would come from the value of the symbol CALLBACK_XEVENT that is bound during execution of a WINTERP callback. [<param0> [<param1> [...] ]] are an optional sequence of STRING values that are passed on to the action procedure. The number of parameters, as well as the contents of the parameters are dependent on the definition of the action procedure. Many action procedures do not take any parameters, in which case, none should be supplied. Note the following caveat from the X Toolkit specification: "It is the responsibility of the caller to ensure that the contents of the <xevent> and [<param0> [<param1> [...] ]] arguments are appropriate for the specified action routine and, if necessary, that the specified widget is realized or sensitive." Example: the following code sets up a callback on pushbutton widget <insertbut_w>. The callback calls method :CALL_ACTION_PROC on the XmText widget <te_w>. The method calls action procedure insert-string() on the XmText widget, which causes insertion of all the string parameters given to the action proc into the XmText instance at the cursor position. (send insertbut_w :set_callback :xmn_activate_callback '(CALLBACK_XEVENT) '( (send te_w :CALL_ACTION_PROC "insert-string" CALLBACK_XEVENT "jimbrowski " "must " "wear " "a " "hat\n") )) #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XtGetValues(XmNchildren/XmNnumChildren) [Motif 1.1 only]: (send <composite_widget> :GET_CHILDREN) --> Returns an array of WIDGETOBJs, the children of <composite_widget>. Returns NIL if no children. This method retrieves the composite-widget resoruces XtNchildren/XmNchildren and XtNnumChildren/XmNnumChildren. Due to flaws in Motif/Xt design, :GET_VALUES on resource XmNchildren cannot be done in a straightforward fashion. I've worked around that limitation by providing this method. (Note that these resources are read-only, so there's no point in having any :SET_VALUES interface for them either.) This method will signal an error if the WIDGETOBJ receiving the :GET_CHILDREN message is not a subclass of the 'Composite' widgetclass. (Which makes sense, since no other widget classes have children...) #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** <SHELL_WIDGET_CLASS> -- the WINTERP shell widget metaclass <SHELL_WIDGET_CLASS> is a widget (pseudo) metaclass for all shell widgets. A shell widget is an object representing a "top level" window that are managed by a window manager (e.g. mwm, the Motif window manager). <SHELL_WIDGET_CLASS> is a subclass of WIDGET_CLASS, so all methods on that metaclass also work on this class as well. *** XtAppCreateShell(): The following create instances of metaclass <SHELL_WIDGET_CLASS>: (send TOP_LEVEL_SHELL_WIDGET_CLASS :new [<name> [<class-name>]] [<args>...]) --> XtAppCreateShell(...topLevelShellWidgetClass...) (send APPLICATION_SHELL_WIDGET_CLASS :new [<name> [<class-name>]] [<args>...]) --> XtAppCreateShell(...applicationShellWidgetClass...) (send OVERRIDE_SHELL_WIDGET_CLASS :new [<name> [<class-name>]] [<args>...]) --> XtAppCreateShell(...overrideShellWidgetClass...) (send TRANSIENT_SHELL_WIDGET_CLASS :new [<name> [<class-name>]] [<args>...]) --> XtAppCreateShell(...transientShellWidgetClass...) [<name>] is an optional string that can be used to qualify the resources of all the children of the shell widget as well as the shell widget itself. (e.g. if <name>=="foo", then the resources corresponding to the shell are specified as "foo*resource". If [<name>] is omitted, then the shell's name defaults to "". One may use this feature to specify multiple logical applications running under WINTERP -- each "application" has its own application_shell or top_level_shell and the widgets in each "application" have their own resource hierarchy. [<class-name>] is an optional string that can be used to set a different class name for the widget hierarchy under this shell widget. If <class-name> is omitted, the shell's class-name defaults to "Winterp" unless the [-class <classname>] command-line option is given, in which case the shell's classname is <classname>. Note that if you want to set <class-name>, you must also set parameter <name>. (Note: setting a <class-name> does not tell WINTERP to look in an application defaults file named <class-name>; setting the application defaults file used by WINTERP can only be set via the [-class <classname>] command-line parameter.) [<args>...] represents a sequence of resource pairs. For more details on resource pairs, see method :SET_VALUES or :NEW on WIDGET_CLASS (above). *** XtRealizeWidget(): (send <Shell_Widget_Instance> :REALIZE) ==> returns <Shell_Widget_Instance> This method causes the shell window and it's subwindows to be created and will make the window appear on the screen. *** XtUnrealizeWidget(): (send <Shell_Widget_Instance> :UNREALIZE) ==> returns <Shell_Widget_Instance> This method destroys the window associated with the shell and all it's subwindows. *** XmIsMotifWMRunning(): (send <Shell_Widget_Instance> :IS_MOTIF_WM_RUNNING) ==> returns T if the motif window manager (mwm) is running, else NIL. ** XtGetValues(XmNargv/XmNargc): (send <Application_Shell_Widget_Instance> :GET_ARGV) or (send <Application_Popup_Shell_Widget_Instance> :GET_ARGV) ==> returns an array of strings. Method :GET_ARGV is valid only for ApplicationShell widgets. It retrieves the resources XmNargv and XmNargc from <Application_Shell_Widget_Instance> and returns an array of strings representing the command line args with which the program was called. Example: to retrieve the command line arguments with which winterp was invoked, do: (send *TOPLEVEL_WIDGET* :GET_ARGV) Where *TOPLEVEL_WIDGET* is a global symbol bound to the (by default) hidden (unmapped) WINTERP main application shell. (see above for more info on *TOPLEVEL_WIDGET*) ** XtSetValues(XmNargv/XmNargc): (send <Application_Shell_Widget_Instance> :SET_ARGV <args>) ==> returns <Application_Shell_Widget_Instance>. Method :SET_ARGV is valid only for ApplicationShell widgets. This sets the XmNargv and XmNargc resources based on the sequence of string arguments <args>. The resources are set on <Application_Shell_Widget_Instance> and this supposedly will allow session managers that the application should start up with the new <args> specified here. ______________________________________________________________________________ ** <POPUP_SHELL_WIDGET_CLASS> -- the WINTERP popup shell widget metaclass <POPUP_SHELL_WIDGET_CLASS> is a (pseudo) metaclass for all popup shells. Popup shells are used for creating dialog boxes, menus, and other interactors that "pop up" from an application window. Like instances of <SHELL_WIDGET_CLASS>, popup shells are "top level" windows that are managed by the window manager. This class is a subclass of <SHELL_WIDGET_CLASS> and WIDGET_CLASS, all methods on those classes also work on this class. *** XtCreatePopupShell(): The following create instances of metaclass <POPUP_SHELL_WIDGET_CLASS>. Optional argument <name> is a string, the name of the widget. <parent> is a WIDGETOBJ that has the new widget instance as popup child. [<args>...] represents a sequence of resource pairs. For more details on resource pairs, see method :SET_VALUES or :NEW on WIDGET_CLASS. (send TOP_LEVEL_POPUP_SHELL_WIDGET_CLASS :new [<name>] <parent> [<args>...]) --> XtCreatePopupShell(topLevelShellWidgetClass) (send APPLICATION_POPUP_SHELL_WIDGET_CLASS :new [<name>] <parent> [<args>...]) --> XtCreatePopupShell(applicationShellWidgetClass) (send OVERRIDE_POPUP_SHELL_WIDGET_CLASS :new [<name>] <parent> [<args>...]) --> XtCreatePopupShell(overrideShellWidgetClass) (send TRANSIENT_POPUP_SHELL_WIDGET_CLASS :new [<name>] <parent> [<args>...]) --> XtCreatePopupShell(transientShellWidgetClass) (send XM_DIALOG_POPUP_SHELL_WIDGET_CLASS :new [<name>] <parent> [<args>...]) --> XmCreateDialogShell() --> XtCreatePopupShell(xmDialogShellWidgetClass) (send XM_MENU_POPUP_SHELL_WIDGET_CLASS :new [<name>] <parent> [<args>...]) --> XmCreateMenuShell() --> XtCreatePopupShell(xmMenuShellWidgetClass) *** XtPopup(): (send <Popup_Shell_Widget_Instance> :POPUP <grabkind>) ==> returns <Popup_Shell_Widget_Instance> This method pops up the shell, keyword symbol <grabkind> determines the kind of grab used: :grab_none, :grab_nonexclusive, :grab_exclusive. *** XtPopDown(): (send <Popup_Shell_Widget_Instance> :POPDOWN) ==> returns <Popup_Shell_Widget_Instance> This method pops down the shell, making it invisible and removing the grab setup by :popup. ** XtGetValues(XmNargv/XmNargc): (send <Application_Popup_Shell_Widget_Instance> :GET_ARGV) ==> returns an array of strings. Method :GET_ARGV is valid only for ApplicationShell widgets. It retrieves the resources XmNargv and XmNargc from <Application_Shell_Widget_Instance> and returns an array of strings representing the command line args with which the program was called. ** XtSetValues(XmNargv/XmNargc): (send <Application_Popup_Shell_Widget_Instance> :SET_ARGV <args>) ==> returns <Application_Popup_Shell_Widget_Instance>. Method :SET_ARGV is valid only for ApplicationShell widgets. This sets the XmNargv and XmNargc resources based on the sequence of string arguments <args>. The resources are set on <Application_Popup_Shell_Widget_Instance> and this supposedly will allow session managers that the application should start up with the new <args> specified here. ______________________________________________________________________________ ** XM_ARROW_BUTTON_WIDGET_CLASS / XM_ARROW_BUTTON_GADGET_CLASS *** equivalent Xt 'WidgetClass': xmArrowButtonWidgetClass xmArrowButtonGadgetClass *** equivalent creation convenience function: (send XM_ARROW_BUTTON_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateArrowButton() (send XM_ARROW_BUTTON_GADGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateArrowButtonGadget() *** XtAddCallback(): #ifdef MOTIF_1.0 In Motif 1.0, :ADD_CALLBACK/:SET_CALLBACK on arrow buttons will use the :ADD_CALLBACK/:SET_CALLBACK methods defined on <WIDGET_CLASS>, the XmAnyCallbackStruct fields defined on those methods will be valid. #endif /* MOTIF_1.0 */ #ifdef MOTIF_1.1 (send <arrow-button> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <arrow-button> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that these methods understand how to get call_data values from the XmArrowButtonCallbackStruct typedef struct { int reason; XEvent *event; int click_count; } XmArrowButtonCallbackStruct; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback CALLBACK_CLICK_COUNT -- a FIXNUM representing the number of clicks upon the button. The click count will only be > 1 when resource :XMN_MULTI_CLICK == :MULTICLICK_KEEP #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XM_BULLETIN_BOARD_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmBulletinBoardWidgetClass *** equivalent creation convenience function: (send XM_BULLETIN_BOARD_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateBulletinBoard() (send XM_BULLETIN_BOARD_WIDGET_CLASS :new [:managed/:unmanaged] :DIALOG ...) --> XmCreateBulletinBoardDialog() ______________________________________________________________________________ ** XM_CASCADE_BUTTON_WIDGET_CLASS / XM_CASCADE_BUTTON_GADGET_CLASS *** equivalent Xt 'WidgetClass': xmCascadeButtonWidgetClass xmCascadeButtonGadgetClass *** equivalent creation convenience function: (send XM_CASCADE_BUTTON_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateCascadeButton() (send XM_CASCADE_BUTTON_GADGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateCascadeButtonGadget() *** XmCascadeButtonHighlight(): (send <cascadebutton> :HIGHLIGHT <highlight_p>) --> returns <cascadebutton> This method draws the shadow highlight around the cascadebutton if <highlight_p> is true, and unhighlights if <highlight_p> is NIL. #ifdef MOTIF_1.1 *** XtGetValues(...XmNsubMenuId...): [Motif 1.1 only -- Motif bug work-around] (send <cascadebutton> :GET_SUB_MENU_WIDGET) ==> this method returns the WIDGETOBJ corresponding to the the widget returned by resource XmNsubMenuId. Why use this instead of XmNsubMenuId?? Because due to some weird Motif 1.1 bug, (probably in motif) doing (send <cascadebutton> :get_values :XMN_SUB_MENU_ID nil) returns <cascadebutton>. ??? #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XM_COMMAND_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmCommandWidgetClass *** equivalent creation convenience function: (send XM_COMMAND_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateCommand() *** XtAddCallback(): (send <commandwidget> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <commandwidget> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that these methods understand how to get call_data values from the XmCommandCallbackStruct: typedef struct { int reason; XEvent *event; XmString value; int length; } XmCommandCallbackStruct; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback CALLBACK_VALUE -- the XmString of the command. CALLBACK_LENGTH -- the length of XmString in CALLBACK_VALUE *** XmCommandGetChild(): (send <commandwidget> :GET_CHILD <symbol>) --> returns a WIDGETOBJ corresponding to <symbol> <symbol> can be :DIALOG_COMMAND_TEXT, :DIALOG_HISTORY_LIST, or :DIALOG_PROMPT_LABEL *** XmCommandAppendValue(): (send <commandwidget> :APPEND_VALUE <value>) --> returns <value>. This method appends the string or XmString <value> to the string in the command area widget. If a normal string is given, it will be converted to an XmString and returned as the method's result. *** XmCommandSetValue(): (send <commandwidget> :SET_VALUE <value>) --> returns <value> This method sets the text in the widget's command area to the string or XmString <value>. If a normal string is given, it will be converted to an XmString and returned as the method's result. *** XmCommandError(): (send <commandwidget> :ERROR <error>) --> returns <error>. This method temporarily displays the string or XmString <error> in the history area of the command widget, the display is cleared upon entry of the next command. If a normal string is given, it will be converted to an XmString and returned as the method's result. *** XtGetValues(XmNhistoryItems/XmNhistoryItemCount): (send <commandwidget> :GET_HISTORY_ITEMS)] --> returns an array of XM_STRING, each representing an item in the command widget's selection box. This method allows retrieval of command widget resource XmNhistoryItems. Due to flaws in Motif/Xt design, :GET_VALUES on resource :XMN_HISTORY_ITEMS cannot be done in a straightforward fashion. I've worked around that limitation by providing this method. ______________________________________________________________________________ ** XM_DRAWING_AREA_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmDrawingAreaWidgetClass *** equivalent creation convenience function: (send XM_DRAWING_AREA_WIDGET_CLASS :new [:managed/:unmanaged] ..) --> XmCreateDrawingArea() *** XtAddCallback(): (send <drawingareawidget> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <drawingareawidget> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that this method knows how to get call_data values from the XmDrawingAreaCallbackStruct: typedef struct { int reason; XEvent *event; Window window; } XmDrawingAreaCallbackStruct; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback CALLBACK_WINDOW -- the Window of the callback ______________________________________________________________________________ ** XM_DRAWN_BUTTON_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmDrawnButtonWidgetClass *** equivalent creation convenience function: (send XM_DRAWN_BUTTON_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateDrawnButton() *** XtAddCallback(): (send <drawnbuttonwidget> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <drawnbuttonwidget> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that these methods understand how to get call_data values from the XmDrawnButtonCallbackStruct: typedef struct { int reason; XEvent *event; Window window; #ifdef MOTIF_1.1 int click_count; /* FIELD EXISTS ONLY IN MOTIF 1.1 */ #endif MOTIF_1.1 } XmDrawnButtonCallbackStruct; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback CALLBACK_WINDOW -- the Window of the callback #ifdef MOTIF_1.1 CALLBACK_CLICK_COUNT -- a FIXNUM representing the number of clicks upon the button. The click count will only be > 1 when resource :XMN_MULTI_CLICK == :MULTICLICK_KEEP #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XM_FILE_SELECTION_BOX_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmFileSelectionBoxWidgetClass *** equivalent creation convenience function: (send XM_FILE_SELECTION_BOX_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateFileSelectionBox() (send XM_FILE_SELECTION_BOX_WIDGET_CLASS :new [:managed/:unmanaged] :dialog ...) --> XmCreateFileSelectionDialog() *** XtAddCallback(): (send <fileselboxwidget> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <fileselboxwidget> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that these methods understand how to get call_data values from the XmFileSelectionBoxCallbackStruct: typedef struct { int reason; XEvent *event; XmString value; int length; XmString mask; int mask_length; #ifdef MOTIF_1.1 XmString dir; /* FIELD EXISTS ONLY IN MOTIF 1.1 */ int dir_length; /* FIELD EXISTS ONLY IN MOTIF 1.1 */ XmString pattern; /* FIELD EXISTS ONLY IN MOTIF 1.1 */ int pattern_length; /* FIELD EXISTS ONLY IN MOTIF 1.1 */ #endif /* MOTIF_1.1 */ } XmFileSelectionBoxCallbackStruct; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback CALLBACK_VALUE -- the XmString corresponding to the current value of resource :XMN_DIR_SPEC CALLBACK_LENGTH -- the length of XmString in CALLBACK_VALUE CALLBACK_MASK -- the XmString corresponding to the current value of resource :XMN_DIR_MASK CALLBACK_MASK_LENGTH -- the length of XmString in CALLBACK_MASK #ifdef MOTIF_1.1 CALLBACK_DIR -- the current base directory (XmString) CALLBACK_DIR_LENGTH -- length of XmString in CALLBACK_DIR CALLBACK_PATTERN -- the search pattern (XmString) CALLBACK_PATTERN_LENGTH -- length of XmString in CALLBACK_PATTERN #endif /* MOTIF_1.1 */ *** XmFileSelectionBoxGetChild(): (send <fileselboxwidget> :GET_CHILD <child_sym>) --> returns a WIDGETOBJ, the child of <fileselboxwidget> corresponding to one of the following keyword symbols: #ifdef MOTIF_1.1 :DIALOG_DIR_LIST :DIALOG_DIR_LIST_LABEL #endif /* MOTIF_1.1 */ :DIALOG_WORK_AREA :DIALOG_SEPARATOR :DIALOG_APPLY_BUTTON :DIALOG_CANCEL_BUTTON :DIALOG_DEFAULT_BUTTON :DIALOG_FILTER_LABEL :DIALOG_FILTER_TEXT :DIALOG_HELP_BUTTON :DIALOG_LIST :DIALOG_LIST_LABEL :DIALOG_OK_BUTTON :DIALOG_SELECTION_LABEL :DIALOG_TEXT *** XmFileSelectionDoSearch(): (send <fileselboxwidget> :DO_SEARCH [<dirmask>]) --> returns <dirmask> This method initiates a directory search. The search will be according to the string or XmString <dirmask>. If <dirmask> is NIL, or not supplied, then the search will use the current directory mask. This method returns <dirmask> as an XmString or NIL. #ifdef MOTIF_1.1 *** XtGetValues(XmNdirListItems/XmNdirListItemCount) [MOTIF_1.1 only]: (send <fileselboxwidget> :GET_DIR_LIST_ITEMS) --> returns an array of XM_STRING, each representing an item in the file-selection box's directory list widget. This method allows retrieval of list widget resource XmNdirListItems. Due to flaws in Motif/Xt design, :GET_VALUES on resource :XMN_DIR_LIST_ITEMS cannot be done in a straightforward fashion. I've worked around that limitation by providing this method. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XtGetValues(XmNfileListItems/XmNfileListItemCount) [MOTIF_1.1 only]: (send <fileselboxwidget> :GET_FILE_LIST_ITEMS) --> returns an array of XM_STRING, each representing an item in the file-selection box's file list widget. This method allows retrieval of list widget resource XmNfileListItems. Due to flaws in Motif/Xt design, :GET_VALUES on resource :XMN_FILE_LIST_ITEMS cannot be done in a straightforward fashion. I've worked around that limitation by providing this method. #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XM_FORM_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmFormWidgetClass *** equivalent creation convenience function: (send XM_FORM_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateForm() (send XM_FORM_WIDGET_CLASS :new [:managed/:unmanaged] :dialog ...) --> XmCreateFormDialog() ______________________________________________________________________________ ** XM_FRAME_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmFrameWidgetClass *** equivalent creation convenience function: (send XM_FRAME_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateFrame() ______________________________________________________________________________ ** XM_LABEL_WIDGET_CLASS / XM_LABEL_GADGET_CLASS *** equivalent Xt 'WidgetClass': xmLabelWidgetClass xmLabelGadgetClass *** equivalent creation convenience function: (send XM_LABEL_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateLabel() (send XM_LABEL_GADGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateLabelGadget() ______________________________________________________________________________ ** XM_LIST_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmListWidgetClass *** equivalent creation convenience function: (send XM_LIST_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateList() (send XM_LIST_WIDGET_CLASS :new [:managed/:unmanaged] :scrolled ...) --> XmCreateScrolledList() Note -- the :scrolled list widget created by XmCreateScrolledList() is anomalous, since it returns a list widget whose parent is of class xmScrolledWindowWidgetClass. Unless special kludgery was added since the last time I looked at the source, this may result in problems in using this widget with managers and constraint manager as <parent>. If that happens, do (send <list_w> :parent) to retrieve the appropriate widget to be managed. *** XtAddCallback(): (send <listwidget> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <listwidget> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that these methods understand how to get call_data values from the XmListCallbackStruct: typedef struct { int reason; XEvent *event; XmString item; int item_length; int item_position; XmString *selected_items; int selected_item_count; #ifdef MOTIF_1.1 int *selected_item_positions;/* EXISTS ONLY IN 1.1 */ #endif /* MOTIF_1.1 */ int selection_type; } XmListCallbackStruct; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback CALLBACK_ITEM -- the selected list item, an XmString. CALLBACK_ITEM_LENGTH -- the length of XmString in CALLBACK_ITEM CALLBACK_ITEM_POSITION -- the position of the selected item in the list, a nonnegative FIXNUM. CALLBACK_SELECTED_ITEMS -- an ARRAY of XmStrings corresponding to the selected items in the list. #ifdef MOTIF_1.1 CALLBACK_SELECTED_ITEM_POSITIONS -- -- an ARRAY of FIXNUMS reprenseting the positions of items in the list widget. #endif /* MOTIF_1.1 */ CALLBACK_SELECTED_ITEM_COUNT -- a FIXNUM, the number of items in CALLBACK_SELECTED_ITEMS and CALLBACK_SELECTED_ITEM_POSITIONS CALLBACK_SELECTION_TYPE -- a SYMBOL, either INITIAL, ADDITION, or MODIFICATION corresponding to the Motif constants XmINITIAL, XmADDITION, or XmMODIFICATION. Note that the callback bindings that are valid depend on the kind of callback you have set up: For :XMN_SINGLE_SELECTION_CALLBACK, :XMN_BROWSE_SELECTION_CALLBACK and :XMN_DEFAULT_ACTION_CALLBACK, the valid symbols are: CALLBACK_WIDGET, CALLBACK_REASON, CALLBACK_XEVENT, CALLBACK_ITEM, CALLBACK_ITEM_LENGTH, CALLBACK_ITEM_POSITION. For :XMN_MULTIPLE_SELECTION_CALLBACK, the valid symbols are: CALLBACK_WIDGET, CALLBACK_REASON, CALLBACK_XEVENT, CALLBACK_ITEM, CALLBACK_ITEM_LENGTH, CALLBACK_ITEM_POSITION, CALLBACK_SELECTED_ITEMS, CALLBACK_SELECTED_ITEM_POSITIONS, CALLBACK_SELECTED_ITEM_COUNT. For :XMN_EXTENDED_SELECTION_CALLBACK, the valid symbols are: callback_widget, callback_reason, callback_xevent, callback_item, callback_item_length, callback_item_position, callback_selected_items, callback_selected_item_count, callback_selection_type, callback_selected_item_positions *** XmListAddItem() (send <listwidget> :ADD_ITEM <item> <position>) --> returns <item> as an XmString. This method adds <item> to <listwidget> at the given position. <item> is a string or XmString. If <item> is given as a string, it is converted to an XmString and that XmString is returned. <position> is an positive fixnum. Specifying 0 will add the item to the end of the list, 1 makes it the first item, 2 the second, etc. *** XmListAddItemUnselected(): (send <listwidget> :ADD_ITEM_UNSELECTED <item> <position>) ==> returns <item> as an XmString. This method adds <item> to <listwidget> at the given position and ensures that <item> is not selected. <item> is a string or XmString. If <item> is given as a string, it is converted to an XmString and that XmString is returned by the method. <position> is an positive fixnum. Specifying 0 will add the item to the end of the list, 1 makes it the first item, 2 the second, etc. #ifdef MOTIF_1.1 *** XmListAddItems() [Motif 1.1 only] (send <listwidget> :ADD_ITEMS <item-seq> <position>) ==> returns <listwidget> This method adds the specified items to the list at the given position. When the items are inserted into the list, they are compared with the current list of selected items. If the any of the new items matches an item on the selected list, it appears selected. <item-seq> is a list or array of strings or XmStrings. Note that if strings are given, they will automatically be converted to XmStrings before being passed to <listwidget>. <position> is an positive fixnum. Specifying 0 will add the item to the end of the list, 1 makes it the first item, 2 the second, etc. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XmListDeleteAllItems() [Motif 1.1 only] (send <listwidget> :DELETE_ALL_ITEMS) ==> returns <listwidget>. XmListDeleteAllItems deletes all items from <listwidget>. #endif /* MOTIF_1.1 */ *** XmListDeleteItem(): (send <listwidget> :DELETE_ITEM <item>) ==> returns <item> as an XmString This method deletes the specified <item> from <listwidget>, giving an XtWarning if <item> doesn't exist. <item> is a string or XmString. If <item> is given as a string, it is converted to an XmString and that XmString is returned by the method. #ifdef MOTIF_1.1 *** XmListDeleteItems() [Motif 1.1 only] (send <listwidget> :DELETE_ITEMS <item-seq>) ==> returns <listwidget> <item-seq> is a list or array of strings or XmStrings. Note that if strings are given, they will automatically be converted to XmStrings before being passed to <listwidget>. This method deletes the specified <item-seq> from <listwidget>, giving an XtWarning if <item> doesn't exist. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XmListDeleteItemsPos() [Motif 1.1 only] (send <listwidget> :DELETE_ITEMS_POS <position> <item-count>) ==> returns <listwidget>. This method deletes the items at <position> from <listwidget>. The number of items to delete at <position> is specified by <item-count>. A position of zero deletes the last item on the list. This method gives an XtWarning if the item doesn't exist. <position> is an positive fixnum. <item-count> is an positive fixnum. #endif /* MOTIF_1.1 */ *** XmListDeletePos(): (send <listwidget> :DELETE_POS <position>) ==> returns <listwidget>. This method deletes the item at <position> from <listwidget>. A position of zero deletes the last item on the list. Gives an XtWarning if the item doesn't exist. <position> is an positive fixnum. *** XmListDeselectAllItems(): (send <listwidget> :DESELECT_ALL_ITEMS) ==> returns <listwidget>. This method unhighlights all selected items and removes all items from the selected items list. *** XmListDeselectItem(): (send <listwidget> :DESELECT_ITEM <item>) ==> returns <item> as an XmString This method removes the specified <item> from the selected list and unhighlights it. <item> is a string or XmString. If <item> is given as a string, it is converted to an XmString and that XmString is returned by the method. *** XmListDeselectPos(): (send <listwidget> :DESELECT_POS <position>) ==> returns <listwidget>. This method removes the item associated with <position> from the selected list and unhighlights it. <position> is an positive fixnum. #ifdef MOTIF_1.1 *** XmListGetMatchPos() [Motif 1.1 only] (send <listwidget> :GET_MATCH_POS <item>) ==> returns an array of FIXNUMS, each representing the position of <item> in <listwidget>. Returns NIL if no matches found for <item>. <item> is a string or XmString. If <item> is given as a string, it is converted to an XmString. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XmListGetSelectedPos() [Motif 1.1 only] (send <listwidget> :GET_SELECTED_POS) ==> returns an array of FIXNUMS, each representing the position of the selected items in <listwidget>. Returns NIL if there are no selected items. #endif /* MOTIF_1.1 */ *** XmListItemExists(): (send <listwidget> :ITEM_EXISTS <item>) ==> returns T if the item is in the specified list widget, else NIL. <item> is a string or XmString. If <item> is given as a string, it is converted to an XmString. #ifdef MOTIF_1.1 *** XmListItemPos() [Motif 1.1 only] (send <listwidget> :ITEM_POS <item>) ==> returns FIXNUM position of the first instance of <item> in <listwidget>. If <item> doesn't exist, returns NIL. <item> is a string or XmString. If <item> is given as a string, it is converted to an XmString. Note that the position of thefirst item in the list is 1, not 0. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XmListReplaceItems() [Motif 1.1 only] (send <listwidget> :REPLACE_ITEMS <old-item-seq> <new-item-seq>) ==> returns <listwidget> This method replaces each specified item of the sequence <old-item-seq> with a corresponding new item from <new-item-seq>. <old-item-seq> and <new-item-seq> is a list or array of strings or XmStrings. Note that if strings are given, they will automatically be converted to XmStrings before being passed to <listwidget>. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XmListReplaceItemsPos() [Motif 1.1 only] (send <listwidget> :REPLACE_ITEMS_POS <item-seq> <position>) ==> returns <listwidget> This method replaces the items beginning at <position> with the items specified in <item-seq>. <item-seq> is a list or array of strings or XmStrings. Note that if strings are given, they will automatically be converted to XmStrings before being passed to <listwidget>. #endif /* MOTIF_1.1 */ *** XmListSelectItem(): (send <listwidget> :SELECT_ITEM <item> [<notify_p>]) ==> returns <item> as an XmString This method adds <item> to the selected items list and highlights it. <item> is a string or XmString. If <item> is given as a string, it is converted to an XmString and that XmString is returned by the method. <notify_p> is an optional boolean parameter. If non-NIL, it will issue a callback indicating an item has been selected. *** XmListSelectPos(): (send <listwidget> :SELECT_POS <position> [<notify_p>]) ==> returns <listwidget>. This method adds the item corresponding to <position> to the selected items list and highlights it. <position> is an positive fixnum. <notify_p> is an optional boolean parameter. If non-NIL, it will issue a callback indicating an item has been selected. #ifdef MOTIF_1.1 *** XmListSetAddMode() [Motif 1.1 only] (send <listwidget> :SET_ADD_MODE <add-mode-p>) ==> returns <listwidget> <add-mode-p> is a boolean. If <add-mode-p> non-NIL, then <listwidget> will be set into add mode. This allows application-control over Add Mode in the extended selection model. #endif /* MOTIF_1.1 */ *** XmListSetBottomItem(): (send <listwidget> :SET_BOTTOM_ITEM <item>) ==> returns <item> as an XmString This method makes <item> be the last visible position in the list. <item> is a string or XmString. If <item> is given as a string, it is converted to an XmString and that XmString is returned by the method. *** XmListSetBottomPos(): (send <listwidget> :SET_BOTTOM_POS <position>) ==> returns <listwidget>. This method makes the item associated with <position> be the last visible position in the list. <position> is an positive fixnum. *** XmListSetHorizPos(): (send <listwidget> :SET_HORIZ_POS <position>) ==> returns <listwidget>. This method scrolls the list horizontally such that the scrollbar reflects <position> in the list. <position> is an positive fixnum. *** XmListSetItem(): (send <listwidget> :SET_ITEM <item>) ==> returns <item> as an XmString This method makes <item> be the first visible item in the list. <item> is a string or XmString. If <item> is given as a string, it is converted to an XmString and that XmString is returned by the method. *** XmListSetPos(): (send <listwidget> :SET_POS <position>) ==> returns <listwidget>. This method makes the item associated with <position> be the first visible element of the list. <position> is an positive fixnum. *** XtGetValues(XmNitems/XmNitemCount): (send <listwidget> :GET_ITEMS) --> returns an array of XM_STRING, each representing an item in the list widget. This method allows retrieval of list widget resource XmNitems. Due to flaws in Motif/Xt design, :GET_VALUES on resource :XMN_ITEMS cannot be done in a straightforward fashion. I've worked around that limitation by providing this method. *** XtGetValues(XmNselectedItems/XmNselectedItemCount): (send <listwidget> :GET_SELECTED_ITEMS) --> returns an array of XM_STRING, each representing a selected item in the list widget. This method allows retrieval of list widget resource XmNselectedItems. Due to flaws in Motif/Xt design, :GET_VALUES on resource :XMN_SELECTED_ITEMS cannot be done in a straightforward fashion. I've worked around that limitation by providing this method. ______________________________________________________________________________ ** XM_MAIN_WINDOW_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmMainWindowWidgetClass *** equivalent creation convenience function: (send XM_MAIN_WINDOW_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateMainWindow() *** XmMainWindowSetAreas(): (send <mainwinwidget> :SET_AREAS <menu> <command> <hscroll> <vscroll> <workregion>) ==> returns <mainwinwidget>. This method is used to attach children to be managed by an instance of XM_MAIN_WINDOW_WIDGET_CLASS. <menu> <command> <hscroll> <vscroll> and <workregion> are all WIDGETOBJs that must be created (with MainWindow as parent) before calling :SET_AREAS. If you don't want to set a particular region, pass NIL as the argument for the particular widget. <menu> specifies the WIDGETOBJ for the MenuBar to be associated with the MainWindow widget The resource name associated with this argument is :XMN_MENU_BAR. <command> specifies the WIDGETOBJ for the command window to be associated with the MainWindow widget. The resource name associated with this argument is :XMN_COMMAND_WINDOW. <hscroll> specifies the WIDGETOBJ for the horizontal ScrollBar to be associated with the MainWindow widget. The resource name associated with this argument is :XMN_HORIZONTAL_SCROLL_BAR. <vscroll> specifies the WIDGETOBJ for the vertical ScrollBar to be associated with the MainWindow widget. The resource name associated with this argument is :XMN_VERTICAL_SCROLL_BAR. <workregion> specifies the WIDGETOBJ for the work window to be associated with the MainWindow widget. The resource name associated with this argument is :XMN_WORK_WINDOW. *** XmMainWindowSep1(): (send <mainwinwidget> :SEP1) ==> returns the WIDGETOBJ corresponding to the first separator widget. The first separator widget is located between the MenuBar and the Command widget. This separator is visible only when resource :XMN_SHOW_SEPARATOR is T. *** XmMainWindowSep2(): (send <mainwinwidget> :SEP2) ==> returns the WIDGETOBJ corresponding to the second separator widget. The second Separator widget is located between the Command widget and the ScrolledWindow. This Separator is visible only when resource :XMN_SHOW_SEPARATOR is T. #ifdef MOTIF_1.1 *** XmMainWindowSep3(): [Motif 1.1 only] (send <mainwinwidget> :SEP3) ==> returns the WIDGETOBJ corresponding to the third separator widget. The third Separator widget is located between the message window and the widget above it. This Separator is visible only when resource :XMN_SHOW_SEPARATOR is T. #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XM_MESSAGE_BOX_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmMessageBoxWidgetClass *** equivalent creation convenience function: (send XM_MESSAGE_BOX_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateMessageBox() (send XM_MESSAGE_BOX_WIDGET_CLASS :new [:managed/:unmanaged] :MESSAGE_DIALOG ...) --> XmCreateMessageDialog() (send XM_MESSAGE_BOX_WIDGET_CLASS :new [:managed/:unmanaged] :ERROR_DIALOG ...) --> XmCreateErrorDialog() (send XM_MESSAGE_BOX_WIDGET_CLASS :new [:managed/:unmanaged] :INFORMATION_DIALOG ...) --> XmCreateInformationDialog() (send XM_MESSAGE_BOX_WIDGET_CLASS :new [:managed/:unmanaged] :QUESTION_DIALOG ...) --> XmCreateQuestionDialog() (send XM_MESSAGE_BOX_WIDGET_CLASS :new [:managed/:unmanaged] :WARNING_DIALOG ...) --> XmCreateWarningDialog() (send XM_MESSAGE_BOX_WIDGET_CLASS :new [:managed/:unmanaged] :WORKING_DIALOG ...) --> XmCreateWorkingDialog() *** XmMessageBoxGetChild(): (send <messageboxwidget> :GET_CHILD <symbol>) --> returns a WIDGETOBJ, the child of <messageboxwidget> corresponding to one of the following keyword <symbol>s: :DIALOG_DEFAULT_BUTTON :DIALOG_SYMBOL_LABEL :DIALOG_MESSAGE_LABEL :DIALOG_OK_BUTTON :DIALOG_CANCEL_BUTTON :DIALOG_HELP_BUTTON :DIALOG_SEPARATOR ______________________________________________________________________________ ** XM_PANED_WINDOW_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmPanedWindowWidgetClass *** equivalent creation convenience function: (send XM_PANED_WINDOW_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreatePanedWindow() ______________________________________________________________________________ ** XM_PUSH_BUTTON_WIDGET_CLASS / XM_PUSH_BUTTON_GADGET_CLASS *** equivalent Xt 'WidgetClass': xmPushButtonWidgetClass xmPushButtonGadgetClass *** equivalent creation convenience function: (send XM_PUSH_BUTTON_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreatePushButton() (send XM_PUSH_BUTTON_GADGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreatePushButtonGadget() *** XtAddCallback(): #ifdef MOTIF_1.0 In Motif 1.0, :ADD_CALLBACK/:SET_CALLBACK on push buttons will use the :ADD_CALLBACK/:SET_CALLBACK methods defined on <WIDGET_CLASS>, the XmAnyCallbackStruct fields defined on those methods will be valid. #endif /* MOTIF_1.0 */ #ifdef MOTIF_1.1 (send <push-button> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <push-button> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that these methods understand how to get call_data values from the XmPushButtonCallbackStruct typedef struct { int reason; XEvent *event; int click_count; } XmPushButtonCallbackStruct; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback CALLBACK_CLICK_COUNT -- a FIXNUM representing the number of clicks upon the button. The click count will only be > 1 when resource :XMN_MULTI_CLICK == :MULTICLICK_KEEP #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XM_ROW_COLUMN_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmRowColumnWidgetClass *** equivalent creation convenience function: (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateRowColumn() #ifdef MOTIF_1.1 (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] ... :WORK_AREA ...) --> XmCreateWorkArea(); #endif /* MOTIF_1.1 */ (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] :RADIO_BOX ...) --> XmCreateRadioBox() #ifdef MOTIF_1.1 (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] :SIMPLE_RADIO_BOX ...) --> XmCreateSimpleRadioBox(); #endif /* MOTIF_1.1 */ (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] :OPTION_MENU ...) --> XmCreateOptionMenu() #ifdef MOTIF_1.1 (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] :SIMPLE_OPTION_MENU ...) --> XmCreateSimpleOptionMenu(); #endif /* MOTIF_1.1 */ (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] :MENU_BAR ...) --> XmCreateMenuBar() #ifdef MOTIF_1.1 (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] :SIMPLE_MENU_BAR ...) --> XmCreateSimpleMenuBar(); #endif /* MOTIF_1.1 */ (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] :POPUP_MENU ...) --> XmCreatePopupMenu() #ifdef MOTIF_1.1 (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] :SIMPLE_POPUP_MENU ...) --> XmCreateSimplePopupMenu(); #endif /* MOTIF_1.1 */ (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] :PULLDOWN_MENU ...) --> XmCreatePulldownMenu() #ifdef MOTIF_1.1 (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] :SIMPLE_PULLDOWN_MENU ...) --> XmCreateSimplePulldownMenu(); #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 (send XM_ROW_COLUMN_WIDGET_CLASS :new [:managed/:unmanaged] :SIMPLE_CHECK_BOX ...) --> XmCreateSimpleCheckBox(); #endif /* MOTIF_1.1 */ *** XtAddCallback(): (send <rowcolwidget> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <rowcolwidget> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that these methods understand how to get call_data values from the XmRowColumnCallbackStruct: typedef struct { int reason; XEvent *event; Widget widget; char *data; char *callbackstruct; } XmRowColumnCallbackStruct; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback If the you're doing (send <rowcolwidget> :ADD_CALLBACK :XMN_ENTRY_CALLBACK ...) or (send <rowcolwidget> :SET_CALLBACK :XMN_ENTRY_CALLBACK ...) then the following symbols may be bound to call_data values from the entry widget in <rowcolwidget> that fired: CALLBACK_ENTRY_WIDGET -- a WIDGETOBJ representing the child of <rowcolwidget> that fired. CALLBACK_ENTRY_REASON -- the reason SYMBOL for an entrywidget of class XM_TOGGLE_BUTTON_GADGET_CLASS or XM_TOGGLE_BUTTON_WIDGET_CLASS CALLBACK_ENTRY_SET -- T if the entrywidget is a set toggle button, NIL if an unset togglebutton. IF not a togglebutton, then results unpredictable. #ifdef MOTIF_1.1 CALLBACK_ENTRY_CLICK_COUNT -- a FIXNUM representing the number of clicks upon the entry-button. The click count will only be > 1 when the entry-button's resource :XMN_MULTI_CLICK is set to :MULTICLICK_KEEP. This callback symbol should only be used if the entry is a button -- unpredictable results will occur for other cases. #endif /* MOTIF_1.1 */ CALLBACK_ENTRY_DATA -- if a callback was set for the entry widget, this will be it's CALLBACKOBJ. Uses for this parameter are unknown and unpredictable. *** Note on XmCreateSimple*() routines: If you use any of the XmCreateSimple*() routines above, you will also want to set the following resources (which are settable only at widget creation time) :XMN_POST_FROM_BUTTON, :XMN_BUTTON_COUNT, :XMN_BUTTONS, :XMN_BUTTON_MNEMONICS, :XMN_BUTTON_MNEMONIC_CHAR_SETS, :XMN_BUTTON_ACCELERATORS, :XMN_BUTTON_ACCELERATOR_TEXT, :XMN_BUTTON_TYPE, :XMN_BUTTON_SET, :XMN_OPTION_LABEL, :XMN_OPTION_MNEMONIC. For example, the following code will create a menu-bar, and the first pulldown of the menu-bar entry ("Files"): (setq menubar_w (send XM_ROW_COLUMN_WIDGET_CLASS :new :managed :simple_menu_bar "menubar" main_w :XMN_BUTTON_COUNT 5 ;create file cascadebuttons in menubar :XMN_BUTTONS #("Files" "Edit" "Fold" "Spindle" "Mutilate") :XMN_BUTTON_MNEMONICS #(#\F #\E #\o #\S #\M) )) (setq pulldown_w (send XM_ROW_COLUMN_WIDGET_CLASS :new :simple_pulldown_menu "pulldown" menubar_w :XMN_POST_FROM_BUTTON 0 ;post pulldown from menubar's "Files" :XMN_BUTTON_COUNT 5 ;create five buttons in this pulldown :XMN_BUTTONS #("Quit" "Open" "Open in New Window" "Save" "Save As") :XMN_BUTTON_MNEMONICS #(#\Q #\O #\N #\S #\A) :XMN_BUTTON_MNEMONIC_CHAR_SETS #("" "" "ISO8859-1" "ISO8859-1" "ISO8859-1") :XMN_BUTTON_ACCELERATORS #("Ctrl<Key>C" "Ctrl<Key>F" "Ctrl<Key>O" "Ctrl<Key>S" "Ctrl<Key>W") :XMN_BUTTON_ACCELERATOR_TEXT #("^C" "^F" "^O" "^S" "^W") :XMN_BUTTON_TYPE #(:PUSHBUTTON :PUSHBUTTON :PUSHBUTTON :PUSHBUTTON :PUSHBUTTON) )) Note: WINTERP does not provide an interface to XmNsimpleCallback, which is the newfangled way Motif expects you to set up callbacks on widgets created by XmCreateSimple*(). Instead, WINTERP employs an already existing means of setting callbacks in the row-column widget -- XmNentryCallback (:XMN_ENTRY_CALLBACK). This is a truly amazing concept for Motif, being able to use the same code and techniques to do slightly different things. Reuse and polymorphism -- what a concept, dude! The following example sets up a callback on pulldown_w which was created by XmCreateSimplePulldownMenu() in the example above. The callback will print the message associated with the function behind each button in the menu: (send pulldown_w :add_callback :xmn_entry_callback ;use instead of XmNsimpleCallback '(CALLBACK_ENTRY_WIDGET) ;gets bound to widget causing c.b. '( ;; (send CALLBACK_ENTRY_WIDGET :name) returns "button_<#>" ;; where <#> is 0 ... (:XMN_BUTTON_COUNT - 1). ;; we use 'read' to return the FIXNUM <#> after truncating the ;; 7 chars "button_" from the front of the string. (case (read (make-string-input-stream (send CALLBACK_ENTRY_WIDGET :name) 7)) (0 (format T "Quit Function Called\n")) (1 (format T "Open Function Called\n")) (2 (format T "Open in New Window Function Called\n")) (3 (format T "Save Function Called\n")) (4 (format T "Save As Function Called\n")) (T (format T "Error\n"))) )) For further examples of using XmCreateSimple*() routines, see ./../examples/fake-app.lsp and ./../examples/RowColumn.lsp. *** XmMenuPosition(): (send <popup_menu> :MENU_POSITION <event>) ==> returns <popup_menu> This method will position a popup menupane at the position specified by event->x_root, event->y_root, where <event> is an XEvent. This method should only be used on a row_column widget created via (send XM_ROW_COLUMN_WIDGET_CLASS :new :popup_menu ...). *** XmOptionLabelGadget(): (send <option_menu> :OPTION_LABEL_GADGET) ==> returns the WIDGETOBJ corresponding to the label gadget created in an <option_menu> instance. This method should only be used on a rowcolumn instance created via (send XM_ROW_COLUMN_WIDGET_CLASS :new :option_menu ...) *** XmOptionButtonGadget(): (send <option_menu> :OPTION_BUTTON_GADGET) ==> returns the WIDGETOBJ corresponding to the cascade button gadget created in an <option_menu> instance. This method should only be used on a rowcolumn instance created via (send XM_ROW_COLUMN_WIDGET_CLASS :new :option_menu ...) #ifdef MOTIF_1.1 *** XmGetPostedFromWidget(): [Motif 1.1 only] (send <menu> :GET_POSTED_FROM_WIDGET) ==> returns the WIDGETOBJ corresponding to the the widget from which the menu was posted. This method returns the WIDGETOBJ from which a menu was posted. An application can use this routine during the activate callback to determine the context in which the menu callback should be interpreted. In a popup, the widget returned is the widget which initiated the post. In a pulldown from a menubar or option menu, then the returned widget is the menubar or option menu. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XtGetValues(...XmNsubMenuId...): [Motif 1.1 only -- Motif bug work-around] (send <rowcolwidget> :GET_SUB_MENU_WIDGET) ==> this method returns the WIDGETOBJ corresponding to the the widget returned by resource XmNsubMenuId. Why use this instead of XmNsubMenuId?? Because due to some weird Motif 1.1 bug, (probably in motif) doing (send <rowcolwidget> :get_values :XMN_SUB_MENU_ID nil) returns <rowcolwidget>. ??? #endif /* MOTIF_1.1 */ *** NOTE on msgs :MENU_POSITION :OPTION_BUTTON_GADGET :OPTION_LABEL_GADGET, GET_POSTED_FROM_WIDGET, and :GET_SUB_MENU_WIDGET: Future versions of WINTERP may create a special POPUP_MENU_CLASS and OPTION_MENU_CLASS subclasses of XM_ROW_COLUMN_WIDGET_CLASS that have :MENU_POSITION and {:OPTION_BUTTON_GADGET,:OPTION_LABEL_GADGET} as methods in order to avoid problems with using these methods on the wrong row column widget variant. ______________________________________________________________________________ ** XM_SCALE_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmScaleWidgetClass *** equivalent creation convenience function: (send XM_SCALE_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateScale() *** XtAddCallback(): (send <scale_widget> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <scale_widget> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that these methods understand how to get call_data values from the XmScaleCallbackStruct: typedef struct { int reason; XEvent * event; int value; } XmScaleCallbackStruct; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback CALLBACK_VALUE -- a FIXNUM representing the slider location. *** XmScaleSetValue(): (send <scale_widget> :SET_VALUE <value>) ==> returns <scale_widget> This method sets the <scale_widget>'s slider position to <value>, a FIXNUM. *** XmScaleGetValue(): (send <scale_widget> :GET_VALUE) --> returns slider value as a FIXNUM ______________________________________________________________________________ ** XM_SCROLLED_WINDOW_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmScrolledWindowWidgetClass *** equivalent creation convenience function: (send XM_SCROLLED_WINDOW_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateScrolledWindow() *** XmScrolledWindowSetAreas(): (send <ScrolledWin_Widget> :SET_AREAS <hscroll> <vscroll> <wregion>) --> returns <ScrolledWin_Widget> This method allows you to add or change the work region controlled by a scrolled window, and set the scrollbars for scrolled windows in which resource :XMN_SCROLLING_POLICY is set to :APPLICATION_DEFINED. <wregion> <hscroll> and <vscroll> are all WIDGETOBJs. Use NIL if you don't want to set a particular parameter. ______________________________________________________________________________ ** XM_SCROLL_BAR_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmScrollBarWidgetClass *** equivalent creation convenience function: (send XM_SCROLL_BAR_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateScrollBar() *** XtAddCallback(): (send <scrollbar_widget> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <scrollbar_widget> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that these methods understand how to get call_data values from the XmScrollBarCallbackStruct: typedef struct { int reason; XEvent * event; int value; int pixel; } XmScrollBarCallbackStruct; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback CALLBACK_VALUE -- a FIXNUM representing the slider location. CALLBACK_PIXEL -- a FIXNUM representing the coordinate of the mouse button selection. For a vertical scrollbar, it's the 'y' coordinate; For a horizontal scrollbar, it's the 'x' coordinate. NOTE: The value is valid only for callbacks :XMN_TO_TOP_CALLBACK/:XMN_TO_BOTTOM_CALLBACK *** XmScrollBarGetValues(): (send <scrollbar_widget> :GET_VALUE) ==> returns a list (<value> <slider_size> <increment> <page_increment>) all of which are FIXNUMs representing the values of resources :XMN_VALUE, :XMN_SLIDER_SIZE, :XMN_INCREMENT, and :XMN_PAGE_INCREMENT respectively. Note that I couldn't call this method :GET_VALUES (for consistency with the name XmScrollBarGetValues()) because it would override method :GET_VALUES on WIDGET_CLASS. *** XmScrollBarSetValues(): (send <scrollbar_widget> :SET_VALUE <value> <slider_size> [[[<increment>] <page_increment>] <notify>]) ==> returns <scrollbar_widget>. <value> is a fixnum specifying the slider position (same as setting the resource :XMN_VALUE) <slider_size> is a fixnum specifying the size of the slider. (same as setting resource :XMN_SLIDER_SIZE). <increment> is an optional fixnum specifying the amount of button increment and decrement. (same as setting resource :XMN_INCREMENT). <page_increment> is an optional fixnum specifying the page increment size. (same as setting resource :XMN_INCREMENT). <notify> is an optional Boolean, if NIL, the value changed callback will not be activated, else it will. Note that I couldn't call this method :SET_VALUES (for consistency with name XmScrollBarSetValues()) because it would override method :SET_VALUES on WIDGET_CLASS. ______________________________________________________________________________ ** XM_SELECTION_BOX_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmSelectionBoxWidgetClass *** equivalent creation convenience function: (send XM_SELECTION_BOX_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateSelectionBox() (send XM_SELECTION_BOX_WIDGET_CLASS :new [:managed/:unmanaged] :dialog ...) --> XmCreateSelectionDialog() (send XM_SELECTION_BOX_WIDGET_CLASS :new [:managed/:unmanaged] :prompt_dialog ...) --> XmCreatePromptDialog() *** XtAddCallback(): (send <selectionbox_widget> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <selectionbox_widget> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that these methods understand how to get call_data values from the XmSelectionBoxCallbackStruct: typedef struct { int reason; XEvent *event; XmString value; int length; } XmSelectionBoxCallbackStruct; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback CALLBACK_VALUE -- an XmString, the value selected from the selectionbox list, or entered into the selectionbox text field. CALLBACK_LENGTH -- the length of XmString CALLBACK_VALUE. *** XmSelectionBoxGetChild(): (send <selectionbox_widget> :get_child <childname>) ==> returns the WIDGETOBJ corresponding to <childname> which is one of the following keyword symbols: :DIALOG_LIST, :DIALOG_LIST_LABEL, :DIALOG_SELECTION_LABEL, :DIALOG_WORK_AREA, :DIALOG_TEXT, :DIALOG_SEPARATOR, :DIALOG_OK_BUTTON, :DIALOG_APPLY_BUTTON, :DIALOG_CANCEL_BUTTON, :DIALOG_HELP_BUTTON, :DIALOG_DEFAULT_BUTTON *** XtGetValues(XmNlistItems/XmNlistItemCount): (send <selectionbox_widget> :GET_LIST_ITEMS) --> returns an array of XM_STRING, each representing a selected item in the selection box's list widget. This method allows retrieval of list widget resource XmNlistItems. Due to flaws in Motif/Xt design, :GET_VALUES on resource :XMN_LIST_ITEMS cannot be done in a straightforward fashion. I've worked around that limitation by providing this method. ______________________________________________________________________________ ** XM_SEPARATOR_WIDGET_CLASS / XM_SEPARATOR_GADGET_CLASS *** equivalent Xt 'WidgetClass': xmSeparatorWidgetClass xmSeparatorGadgetClass *** equivalent creation convenience function: (send XM_SEPARATOR_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateSeparator() (send XM_SEPARATOR_GADGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateSeparatorGadget() ______________________________________________________________________________ ** XM_TEXT_WIDGET_CLASS // XM_TEXT_FIELD_WIDGET_CLASS *** equivalent Xt 'WidgetClass': xmTextWidgetClass, xmTextFieldWidgetClass *** equivalent creation convenience function: #ifdef MOTIF_1.1 (send XM_TEXT_FIELD_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateTextField() #endif /* MOTIF_1.1 */ (send XM_TEXT_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateText() (send XM_TEXT_WIDGET_CLASS :new [:managed/:unmanaged] :scrolled ...) --> XmCreateScrolledText() Note -- the :scrolled text widget created by XmCreateScrolledText() is anomalous, since it returns a text widget whose parent is of class xmScrolledWindowWidgetClass. Unless special kludgery was added since the last time I looked at the source, this may result in problems in using this widget with managers and constraint manager as <parent>. If that happens, do (send <list_w> :parent) to retrieve the appropriate widget to be managed. *** XtAddCallback(): (send <text> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <text> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that these methods understand how to get call_data values from the XmTextVerifyCallbackStruct: typedef struct { int reason; XEvent *event; Boolean doit; XmTextPosition currInsert, newInsert; XmTextPosition startPos, endPos; XmTextBlock text; } XmTextVerifyCallbackStruct, *XmTextVerifyPtr; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback CALLBACK_DOIT -- this is always bound to T, but if you set it to NIL within the body of the callback code, you can prevent the action that caused the callback from occuring. This field is only valid for :XMN_LOSING_FOCUS_CALLBACK, :XMN_MODIFY_VERIFY_CALLBACK, and :XMN_MOTION_VERIFY_CALLBACKS. CALLBACK_CUR_INSERT -- a FIXNUM, the current position of the insert cursor. This field is only valid for: :XMN_LOSING_FOCUS_CALLBACK, :XMN_MODIFY_VERIFY_CALLBACK, and :XMN_MOTION_VERIFY_CALLBACKS. CALLBACK_NEW_INSERT -- a FIXNUM, the position at which the user attempted to position the insert cursor. This field is only valid for: :XMN_LOSING_FOCUS_CALLBACK, :XMN_MODIFY_VERIFY_CALLBACK, and :XMN_MOTION_VERIFY_CALLBACKS. CALLBACK_START_POS -- a FIXNUM, the starting position of the text to modify. This field is only valid for: :XMN_LOSING_FOCUS_CALLBACK, and :XMN_MODIFY_VERIFY_CALLBACK. CALLBACK_END_POS -- a FIXNUM, the ending position of the text to modify. This field is only valid for: :XMN_LOSING_FOCUS_CALLBACK, and :XMN_MODIFY_VERIFY_CALLBACK. CALLBACK_TEXT -- A STRING, holds the textual information that was inserted. This field is only valid for :XMN_MODIFY_VERIFY_CALLBACK. *** XmTextClearSelection() // XmTextFieldClearSelection(): (send <text> :CLEAR_SELECTION [<xevent>]) --> returns <text> This method clears the primary selection in the Text widget. The optional <xevent> parameter is an XEVENT object from which the event-time is taken. Most often one would just pass in the value of callback symbol CALLBACK_XEVENT. If the <xevent> argument is missing, then 'CurrentTime' (Motif 1.0) or 'XtLastTimestampProcessed()' (Motif 1.1) is used. #ifdef MOTIF_1.1 *** XmTextCopy() // XmTextFieldCopy() [Motif 1.1 only]: (send <text> :COPY [<xevent>]) --> Returns T normally; returns NIL if the primary selection is NULL, if the widget doesn't own the primary selection, or if unable to gain ownership of the clipboard selection. This method copies the primary selection to the clipboard. The optional <xevent> parameter is an XEVENT object from which the event-time is taken. Most often one would just pass in the value of callback symbol CALLBACK_XEVENT. If the <xevent> argument is missing, then 'CurrentTime' (Motif 1.0) or 'XtLastTimestampProcessed()' (Motif 1.1) is used. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XmTextCut() // XmTextFieldCut() [Motif 1.1 only]: (send <text> :CUT [<xevent>]) --> Returns T normally; returns NIL if the primary selection is NULL, if the widget doesn't own the primary selection, or if unable to gain ownership of the clipboard selection. This method copies the primary selected text to the clipboard and then deletes the primary selected text. Calling this method will also invoke the widget's XmNmodifyVerifyCallback and XmNvalueChangedCallback callbacks. The optional <xevent> parameter is an XEVENT object from which the event-time is taken. Most often one would just pass in the value of callback symbol CALLBACK_XEVENT. If the <xevent> argument is missing, then 'CurrentTime' (Motif 1.0) or 'XtLastTimestampProcessed()' (Motif 1.1) is used. #endif /* MOTIF_1.1 */ *** XmTextDisableRedisplay() [MOTIF_1.0] // _XmTextDisableRedisplay() [MOTIF_1.1] (send <text_widget> :DISABLE_REDISPLAY <loses-backingstore-p>) --> returns <text_widget> This method is useful to call before making a series of updates to the text widget's string value. It prevents the changes from being displayed until message :ENABLE_REDISPLAY is received. <loses-backingstore-p> is a boolean. If true, then the text widget loses backingstore, I guess (couldn't find documentation on this). Note that in Motif 1.1, this function has changed its name to _XmTextDisableRedisplay(), and is not documented as being external because it is missing from Xm/Text.h. Programs that rely on this method may break in the future. Note that this method is defined only on the XM_TEXT_WIDGET_CLASS, it doesn't exist for XM_TEXT_FIELD_WIDGET_CLASS. *** XmTextEnableRedisplay() [MOTIF_1.0] // : _XmTextEnableRedisplay() [MOTIF_1.1]: (send <text_widget> :ENABLE_REDISPLAY) --> returns <text_widget> This method allows changes made to the text widget to be displayed after the text widget has received a message :DISABLE_REDISPLAY. Note that in Motif 1.1, this function has changed its name to _XmTextEnableRedisplay(), and is not documented as being external because it is missing from Xm/Text.h. Programs that rely on this method may break in the future. Note that this method is defined only on the XM_TEXT_WIDGET_CLASS, it doesn't exist for XM_TEXT_FIELD_WIDGET_CLASS. #ifdef MOTIF_1.1 *** XmTextGetAddMode() // XmTextFieldGetAddMode() [Motif 1.1 only]: (send <text> :GET_ADD_MODE) --> Returns T if the text widget is in add mode, else NIL. See method :SET_ADD_MODE on <text> for details on add-mode. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XmTextGetBaseline() // XmTextFieldGetBaseline() [Motif 1.1 only]: (send <text> :GET_BASELINE) --> Returns a FIXNUM value that indicates the x position of the first baseline in the Text widget, relative to the x position of the top of the widget. The calculation takes into account the margin height, shadow thickness, highlight thickness, and font ascent of the first font in the fontlist. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XmTextGetCursorPosition() // XmTextFieldGetCursorPosition() [Motif 1.1 only]: (send <text> :GET_CURSOR_POSITION) --> returns a FIXNUM, the position of the insert cursor as an index (0 based) into the text widget's string value. This method seems to be exactly the same as :GET_INSERTION_POSITION. I'm providing it for the sake of completeness, because I cannot possibly know whether this method will take on some special significance in some future version of Motif. #endif /* MOTIF_1.1 */ *** XmTextGetEditable() // XmTextFieldGetEditable(): (send <text> :GET_EDITABLE) --> returns T if editable, NIL otherwise. This is the same as the value of resource :XMN_EDITABLE. *** XmTextGetInsertionPosition() // XmTextFieldGetInsertionPosition(): (send <text> :GET_INSERTION_POSITION) --> returns a FIXNUM, the position of the insert cursor as an index (0 based) into the text widget's string value. This method returns the value of resource :XMN_TEXT_POSITION. *** XmTextGetLastPosition() // XmTextFieldGetLastPosition(): (send <text> :GET_LAST_POSITION) --> Returns a FIXNUM indicating the position of the last character in the text buffer. This is an integer number of characters from the beginning of the buffer. The first character position is 0. Note: this method will return an error if you are using Motif 1.0 on a non-HPUX system. In Motif 1.0, the function corresponding to this method, XmTextGetLastPosition(), was not documented. On most Motif's it was still externally accessible (i.e. not defined as "static" in Xm/Text.c.). Since the functionality provided by the procedure seemed useful, I decided to interface it, even though it was undocumented. Unfortunately, a few bright vendors with nothing better to do decided to change the OSF/Motif 1.0 source so that the procedure is not accessible (declared the procedure "static") thereby causing compilation problems when porting WINTERP to other vendor's Motif 1.0. I know that the function exists in HP's Motif 1.0, but cannot know whether other vendors will decide to make gratuitous changes to the Motif source. Therefore, for all Motif 1.0 non-HPUX systems, calling this method will signal an error. If you know your version of Motif 1.0 is "pure", and you need this functionality, the changes you need to make in ./../src-server/wc_Text.c should be obvious. A better solution would be to use Motif 1.1. For Motif 1.1 this functionality is documented and defined, so don't worry about it. *** XmTextGetMaxLength() // XmTextFieldGetMaxLength(): (send <text> :GET_MAX_LENGTH) --> returns a FIXNUM, the maximum length of a text string entered into <text> from the keyboard. *** XmTextGetSelection() // XmTextFieldGetSelection(): (send <text> :GET_SELECTION) --> returns a string, the value of the primary selection; if no text is selected, an empty string is returned. *** XmTextGetSelectionPosition() // XmTextFieldGetSelectionPosition(): (send <text> :GET_SELECTION_POSITION) --> returns a "dotted pair" (<left_pos> . <right_pos>): Taking 'car' of this result returns <left_pos> which is a FIXNUM representing the position of the left side of the primary selection. Taking 'cdr' of the result returns <right_pos> which is a FIXNUM representing the position if the right side of the selection. Returns NIL if the widget doesn't own the primary selection. Note: this method will return an error if you are using Motif 1.0 on a non-HPUX system. In Motif 1.0, the function corresponding to this method, XmTextGetSelectionPosition(), was not documented. On most Motif's it was still externally accessible (i.e. not defined as "static" in Xm/Text.c.). Since the functionality provided by the procedure seemed useful, I decided to interface it, even though it was undocumented. Unfortunately, a few bright vendors with nothing better to do decided to change the OSF/Motif 1.0 source so that the procedure is not accessible (declared the procedure "static") thereby causing compilation problems when porting WINTERP to other vendor's Motif 1.0. I know that the function exists in HP's Motif 1.0, but cannot know whether other vendors will decide to make gratuitous changes to the Motif source. Therefore, for all Motif 1.0 non-HPUX systems, calling this method will signal an error. If you know your version of Motif 1.0 is "pure", and you need this functionality, the changes you need to make in ./../src-server/wc_Text.c should be obvious. A better solution would be to use Motif 1.1. For Motif 1.1 this functionality is documented and defined, so don't worry about it. *** XmTextGetSource(): No interface to this method exists in the current version of WINTERP. *** XmTextGetString() // XmTextFieldGetString(): (send <text> :GET_STRING) --> returns the string presented/edited in the text edit widget. *** XmTextGetTopCharacter(): (send <text_widget> :GET_TOP_CHARACTER) ---> returns a FIXNUM representing the number of characters from the beginning of the text buffer occuring before the first character being displayed in <text_widget>. This method returns the value of the :XMN_TOP_CHARACTER resource. Note that this method is defined only on the XM_TEXT_WIDGET_CLASS, it doesn't exist for XM_TEXT_FIELD_WIDGET_CLASS. [Note: the name XmTextGetTopPosition() was changed to XmTextGetTopCharacter() in Motif patch 1.01. People using WINTERP on HPUX 7.0 (which uses the unpatched Motif 1.0) should note this gratuitous name change in Motif.] #ifdef MOTIF_1.1 *** XmTextInsert() // XmTextFieldInsert() [Motif 1.1 only]: (send <text> :INSERT <position> <value>) --> Returns <text>. This method inserts a character string <value> into the text string in the Text widget. The string is inserted after the character position specified by the FIXNUM <position>. The first position in the text widget is at zero. This routine also calls the widget's XmNmodifyVerifyCallback and XmNvalueChangedCallback callbacks. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XmTextPaste() // XmTextFieldPaste() [Motif 1.1 only]: (send <text> :PASTE) --> returns T normally; returns NIL if the primary selection is NULL or if the widget doesn't own the primary selection. This method inserts the clipboard selection at the destination cursor. If resource :XMN_PENDING_DELETE is True and the destination cursor is inside the current selection, the clipboard selection replaces the selected text. Calling this method also invokes the widget's XmNmodifyVerifyCallback and XmNvalueChangedCallback callbacks. #endif /* MOTIF_1.1 */ *** XmTextPosToXY() // XmTextFieldPosToXY(): (send <text> :POS_TO_XY <position>) --> returns a "dotted pair" (<x> . <y>). Taking 'car' of the result returns <x>, a FIXNUM representing the pixel x position corresponding to <position>. 'cdr' of the result returns <y>, a FIXNUM representing the pixel y position corresponding to <position>. Returns NIL if <position> is not displayed in the widget. The positions returned by this method are relative to the upper left corner of the widget. <position> is a FIXNUM representing the zero-based character index in <text>. Note: this method will return an error if you are using Motif 1.0 on a non-HPUX system. In Motif 1.0, the function corresponding to this method, XmTextPosToXY(), was not documented. On most Motif's it was still externally accessible (i.e. not defined as "static" in Xm/Text.c.). Since the functionality provided by the procedure seemed useful, I decided to interface it, even though it was undocumented. Unfortunately, a few bright vendors with nothing better to do decided to change the OSF/Motif 1.0 source so that the procedure is not accessible (declared the procedure "static") thereby causing compilation problems when porting WINTERP to other vendor's Motif 1.0. I know that the function exists in HP's Motif 1.0, but cannot know whether other vendors will decide to make gratuitous changes to the Motif source. Therefore, for all Motif 1.0 non-HPUX systems, calling this method will signal an error. If you know your version of Motif 1.0 is "pure", and you need this functionality, the changes you need to make in ./../src-server/wc_Text.c should be obvious. A better solution would be to use Motif 1.1. For Motif 1.1 this functionality is documented and defined, so don't worry about it. #ifdef MOTIF_1.1 *** XmTextRemove() // XmTextFieldRemove() [Motif 1.1 only]: (send <text> :REMOVE) --> Returns T normally; returns NIL if the primary selection is NULL or if the widget doesn't own the primary selection. This method deletes the primary selected text and calls the widget's XmNmodifyVerifyCallback and XmNvalueChangedCallback callbacks if there is a selection. #endif /* MOTIF_1.1 */ *** XmTextReplace() // XmTextFieldReplace(): (send <text> :REPLACE <from-pos> <to-pos> <string>) --> returns <text_widget>. This method replaces part of the text string displayed by <text> with <string> a STRING value. <from-pos> and <to-pos> are FIXNUMs which represent the indexes of the character segment to be replaced. If <from-pos>==<to-pos> the <string> is inserted after <from-pos>. The value 0 represents the first position in the text widget. This method also calls the widget's XmNmodifyVerifyCallback and XmNvalueChangedCallback callbacks. *** XmTextScroll(): (send <text_widget> :SCROLL <n>) --> returns <text_widget>. This method will scroll the text displayed by the text widget up or down by <n> lines. If <n> is a positive FIXNUM, the text moves upward. If <n> is a negative FIXNUM, the text moves down. Note that this method is defined only on the XM_TEXT_WIDGET_CLASS, it doesn't exist for XM_TEXT_FIELD_WIDGET_CLASS. Note: this method will return an error if you are using Motif 1.0 on a non-HPUX system. In Motif 1.0, the function corresponding to this method, XmTextScroll(), was not documented. On most Motif's it was still externally accessible (i.e. not defined as "static" in Xm/Text.c.). Since the functionality provided by the procedure seemed useful, I decided to interface it, even though it was undocumented. Unfortunately, a few bright vendors with nothing better to do decided to change the OSF/Motif 1.0 source so that the procedure is not accessible (declared the procedure "static") thereby causing compilation problems when porting WINTERP to other vendor's Motif 1.0. I know that the function exists in HP's Motif 1.0, but cannot know whether other vendors will decide to make gratuitous changes to the Motif source. Therefore, for all Motif 1.0 non-HPUX systems, calling this method will signal an error. If you know your version of Motif 1.0 is "pure", and you need this functionality, the changes you need to make in ./../src-server/wc_Text.c should be obvious. A better solution would be to use Motif 1.1. For Motif 1.1 this functionality is documented and defined, so don't worry about it. #ifdef MOTIF_1.1 *** XmTextSetAddMode() // XmTextFieldSetAddMode() [Motif 1.1 only]: (send <text> :SET_ADD_MODE <add-modeP>) --> returns <text> This method controls whether or not the Text widget is in Add Mode. When <add-modeP> is T, the widget is set to Add Mode and the insert cursor can be moved without disturbing the primary selection. Else the primary selection is disturbed by cursor movement. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XmTextSetCursorPosition() // XmTextFieldSetCursorPosition() [Motif 1.1 only]: (send <text> :SET_CURSOR_POSITION <position>) --> returns <text> This method seems to be exactly the same as :SET_INSERTION_POSITION. I'm providing it for the sake of completeness, because I cannot possibly know whether this method will take on some special significance in some future version of Motif. #endif /* MOTIF_1.1 */ *** XmTextSetEditable() // XmTextFieldSetEditable(): (send <text> :SET_EDITABLE <editableP>) --> returns <text> This method sets the edit permission of the <text>. If <editableP> is NIL, then keyboard input will not edit text, otherwise users may edit the text. This method sets the resource :XMN_EDITABLE. #ifdef MOTIF_1.1 *** XmTextSetHighlight() // XmTextFieldSetHighlight() [Motif 1.1 only]: (send <text> :SET_HIGHLIGHT <leftpos> <rightpos> <highlightmode>) --> Returns <text> This method highlights text between the two specified character positions <leftpos> and <rightpos>. The <highlightmode> parameter determines the type of highlighting, e.g. :HIGHLIGHT_NORMAL, :HIGHLIGHT_SELECTED, and :HIGHLIGHT_SECONDARY_SELECTED. Note that highlighting text merely changes the visual appearance of the text; it does not set the selection. #endif /* MOTIF_1.1 */ *** XmTextSetInsertionPosition() // XmTextFieldSetInsertionPosition(): (send <text> :SET_INSERTION_POSITION <position>) --> returns <text> This method sets the insertion cursor position of the Text widget to index <position>, a FIXNUM. This routine also calls the widget's XmNmotionVerifyCallback callbacks if the insertion cursor position changes. *** XmTextSetMaxLength() // XmTextFieldSetMaxLength(): (send <text> :SET_MAX_LENGTH <max_length>) --> returns <text> This method sets the value of the current maximum allowable length of a text string entered from the keyboard to <max_length>, a FIXNUM. The maximum allowable length prevents the user from entering a text string from the keyboard that is larger than this limit. Strings that are entered using the :XMN_STRING resource or the :SET_STRING method ignore this resource. *** XmTextSetSelection() // XmTextFieldSetSelection(): (send <text> :SET_SELECTION <firstpos> <lastpos> [<xevent>]) --> returns <text>. This method sets the primary selection in <text>. The selection is set between indexes <firstpos> and <lastpos>, both FIXNUMs. Calling this method will also set the insertion cursor position to <lastpos> and call the XmNmotionVerifyCallback callbacks. The optional <xevent> parameter is an XEVENT object from which the event-time is taken. Most often one would just pass in the value of callback symbol CALLBACK_XEVENT. If the <xevent> argument is missing, then 'CurrentTime' (Motif 1.0) or 'XtLastTimestampProcessed()' (Motif 1.1) is used. *** XmTextSetSource(): No interface to this method exists in the current version of WINTERP. *** XmTextSetString() // XmTextFieldSetString(): (send <text> :SET_STRING <string>) --> returns <text_widget> This method sets the string value of the Text widget. This routine calls the widget's XmNmodifyVerifyCallback and XmNvalueChangedCallback callbacks. It also sets the insertion cursor position to the beginning of the string and calls the widget's XmNmotionVerifyCallback callbacks. *** XmTextSetTopCharacter(): (send <text_widget> :SET_TOP_CHARACTER <top_position>) --> returns <text_widget>. This method sets the first character to be displayed by <text_widget> to be the character whose index is the FIXNUM <top_position>. If resource :XMN_EDIT_MODE is set to :MULTI_LINE_EDIT, then the line of text that contains <top_position> is displayed at the top of the widget without shifting the text left or right. Note that this method is defined only on the XM_TEXT_WIDGET_CLASS, it doesn't exist for XM_TEXT_FIELD_WIDGET_CLASS. [Note: the name XmTextSetTopPosition() was changed to XmTextSetTopCharacter() in Motif patch 1.01. People using WINTERP on HPUX 7.0 (which includes the unpatched Motif 1.0) should note this gratuitous name change in Motif.] *** XmTextShowPosition() // XmTextFieldShowPosition(): (send <text> :SHOW_POSITION <position>) --> returns <text_widget> This method forces the text at the specified FIXNUM index <position> to be displayed. If the resource :XMN_AUTO_SHOW_CURSOR_POSITION is set to 'T', the insert cursor is also set to <position>. *** XmTextXYToPos() // XmTextFieldXYToPos(): (send <text> :XY_TO_POS <x> <y>) --> returns a FIXNUM representing the character position nearest to the specified FIXNUM positions <x> and <y>. These positions are pixel coordinates relative to the upper left corner of the text widget. Note: this method will return an error if you are using Motif 1.0 on a non-HPUX system. In Motif 1.0, the function corresponding to this method, XmTextXYToPos(), was not documented. On most Motif's it was still externally accessible (i.e. not defined as "static" in Xm/Text.c.). Since the functionality provided by the procedure seemed useful, I decided to interface it, even though it was undocumented. Unfortunately, a few bright vendors with nothing better to do decided to change the OSF/Motif 1.0 source so that the procedure is not accessible (declared the procedure "static") thereby causing compilation problems when porting WINTERP to other vendor's Motif 1.0. I know that the function exists in HP's Motif 1.0, but cannot know whether other vendors will decide to make gratuitous changes to the Motif source. Therefore, for all Motif 1.0 non-HPUX systems, calling this method will signal an error. If you know your version of Motif 1.0 is "pure", and you need this functionality, the changes you need to make in ./../src-server/wc_Text.c should be obvious. A better solution would be to use Motif 1.1. For Motif 1.1 this functionality is documented and defined, so don't worry about it. ______________________________________________________________________________ ** XM_TOGGLE_BUTTON_WIDGET_CLASS / XM_TOGGLE_BUTTON_GADGET_CLASS *** equivalent Xt 'WidgetClass': xmToggleButtonWidgetClass xmToggleButtonGadgetClass *** equivalent creation convenience function: (send XM_TOGGLE_BUTTON_WIDGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateToggleButton() (send XM_TOGGLE_BUTTON_GADGET_CLASS :new [:managed/:unmanaged] ...) --> XmCreateToggleButtonGadget() *** XtAddCallback(): (send <togglebutton> :ADD_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ (send <togglebutton> :SET_CALLBACK ...) --> returns: <callback_id_object> of type CALLBACKOBJ These methods work just like the :ADD_CALLBACK/:SET_CALLBACK methods on WIDGET_CLASS except that these methods understand how to get call_data values from the XmToggleButtonCallbackStruct: typedef struct { int reason; XEvent * event; int set; } XmToggleButtonCallbackStruct; Specifying one or more of the following symbols in the callback bindings list will bind that symbol's value in the lexical environment of the callback: CALLBACK_WIDGET -- the WIDGETOBJ of the callback CALLBACK_REASON -- the reason symbol for the callback CALLBACK_XEVENT -- the Xevent* that caused the callback CALLBACK_SET -- T if the togglebutton causing the callback is set, else NIL. *** XmToggleButtonGetState() / XmToggleButtonGadgetGetState(): (send <togglebutton> :GET_STATE) --> returns T if the toggle button is set, else NIL *** XmToggleButtonSetState() / XmToggleButtonGadgetSetState(): (send <togglebutton> :SET_STATE <state_p> <notify_p>) --> returns <togglebutton>. This method sets the state of the togglebutton to OFF if boolean <state_p> is NIL, else it set the state to ON <notify_p> -- if not NIL, :xmn_value_changed_callback gets called. ============================================================================= * WINTERP <--> Motif resources ______________________________________________________________________________ ** XmRAcceleratorTable: *** Type Information: Resource representation type XmRAcceleratorTable corresponds to the atomic type XT_ACCELERATORS as returned by primitive XT_PARSE_ACCELERATOR_TABLE. One may set XmRAcceleratorTable resources by specifying a STRING accelerator table, just as you would in file $HOME/.Xdefaults. Alternatively, one can use the result of :get_values on another widget's XmRAcceleratorTable resource or use primitive XT_PARSE_ACCELERATOR_TABLE as a XmRAcceleratorTable value. For more information on the syntax of the string representation of accelerator tables, see the X11 documentation "X Toolkit Intrinsics -- C Language Interface": "Appendix B: Translation Table Syntax" and "Chapter 10: Translation Management". *** Resource names and the widget classes they apply to: :XMN_TEXT_ACCELERATORS XmNtextAccelerators XM_SELECTION_BOX_WIDGET_CLASS :XMN_ACCELERATORS XmNaccelerators <WIDGET_CLASS> #ifdef MOTIF_1.1 XM_BULLETIN_BOARD_WIDGET_CLASS #endif ______________________________________________________________________________ ** XmRAlignment: *** Type Information: Resource representation type XmRAlignment corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :ALIGNMENT_BEGINNING XmALIGNMENT_BEGINNING :ALIGNMENT_CENTER XmALIGNMENT_CENTER :ALIGNMENT_END XmALIGNMENT_END You may also specify a STRING value which will be automatically converted to XmRAlignment by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_ALIGNMENT XmNalignment XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS :XMN_MESSAGE_ALIGNMENT XmNmessageAlignment XM_MESSAGE_BOX_WIDGET_CLASS :XMN_ENTRY_ALIGNMENT XmNentryAlignment XM_ROW_COLUMN_WIDGET_CLASS ______________________________________________________________________________ ** XmRArrowDirection: *** Type Information: Resource representation type XmRArrowDirection corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :ARROW_UP XmARROW_UP :ARROW_DOWN XmARROW_DOWN :ARROW_LEFT XmARROW_LEFT :ARROW_RIGHT XmARROW_RIGHT You may also specify a STRING value which will be automatically converted to XmRArrowDirection by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_ARROW_DIRECTION XmNarrowDirection XM_ARROW_BUTTON_WIDGET_CLASS XM_ARROW_BUTTON_GADGET_CLASS ______________________________________________________________________________ ** XmRAttachment: *** Type Information: Resource representation type XmRAttachment corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :ATTACH_NONE XmATTACH_NONE :ATTACH_FORM XmATTACH_FORM :ATTACH_OPPOSITE_FORM XmATTACH_OPPOSITE_FORM :ATTACH_WIDGET XmATTACH_WIDGET :ATTACH_OPPOSITE_WIDGET XmATTACH_OPPOSITE_WIDGET :ATTACH_POSITION XmATTACH_POSITION :ATTACH_SELF XmATTACH_SELF You may also specify a STRING value which will be automatically converted to XmRAttachment by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_TOP_ATTACHMENT XmNtopAttachment XM_FORM_WIDGET_CLASS :XMN_BOTTOM_ATTACHMENT XmNbottomAttachment XM_FORM_WIDGET_CLASS :XMN_LEFT_ATTACHMENT XmNleftAttachment XM_FORM_WIDGET_CLASS :XMN_RIGHT_ATTACHMENT XmNrightAttachment XM_FORM_WIDGET_CLASS ______________________________________________________________________________ ** XmRBoolean: *** Type Information: Resource representation type XmRBoolean corresponds to any WINTERP-Lisp value. If the value is NIL, then the value is the boolean FALSE, any other value is interpreted as boolean TRUE. You may also specify a STRING value which will be automatically converted to XmRBoolean by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_ANCESTOR_SENSITIVE XmNancestorSensitive <WIDGET_CLASS> <SHELL_WIDGET_CLASS> :XMN_INPUT XmNinput <SHELL_WIDGET_CLASS> :XMN_SENSITIVE XmNsensitive <WIDGET_CLASS> :XMN_ALLOW_SHELL_RESIZE XmNallowShellResize #ifdef MOTIF_1.0 <SHELL_WIDGET_CLASS> XM_MENU_POPUP_SHELL_WIDGET_CLASS #endif #ifdef MOTIF_1.1 <SHELL_WIDGET_CLASS> #endif :XMN_SAVE_UNDER XmNsaveUnder #ifdef MOTIF_1.0 <SHELL_WIDGET_CLASS> XM_MENU_POPUP_SHELL_WIDGET_CLASS #endif #ifdef MOTIF_1.1 <SHELL_WIDGET_CLASS> #endif :XMN_OVERRIDE_REDIRECT XmNoverrideRedirect <SHELL_WIDGET_CLASS> :XMN_WAIT_FOR_WM XmNwaitForWm <SHELL_WIDGET_CLASS> :XMN_TRANSIENT XmNtransient <SHELL_WIDGET_CLASS> :XMN_ICONIC XmNiconic <SHELL_WIDGET_CLASS> :XMN_MAPPED_WHEN_MANAGED XmNmappedWhenManaged <WIDGET_CLASS> :XMN_ALLOW_OVERLAP XmNallowOverlap XM_BULLETIN_BOARD_WIDGET_CLASS :XMN_AUTO_UNMANAGE XmNautoUnmanage XM_BULLETIN_BOARD_WIDGET_CLASS XM_COMMAND_WIDGET_CLASS XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_DEFAULT_POSITION XmNdefaultPosition XM_BULLETIN_BOARD_WIDGET_CLASS XM_COMMAND_WIDGET_CLASS :XMN_NO_RESIZE XmNnoResize XM_BULLETIN_BOARD_WIDGET_CLASS :XMN_PUSH_BUTTON_ENABLED XmNpushButtonEnabled XM_DRAWN_BUTTON_WIDGET_CLASS :XMN_LIST_UPDATED XmNlistUpdated XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_RUBBER_POSITIONING XmNrubberPositioning XM_FORM_WIDGET_CLASS :XMN_RESIZABLE XmNresizable XM_FORM_WIDGET_CLASS :XMN_TRAVERSAL_ON XmNtraversalOn #ifdef MOTIF_1.0 <XM_GADGET_CLASS> <XM_PRIMITIVE_WIDGET_CLASS> XM_SCALE_WIDGET_CLASS #end #ifdef MOTIF1.1 XM_CASCADE_BUTTON_WIDGET_CLASS XM_CASCADE_BUTTON_GADGET_CLASS XM_DRAWN_BUTTON_WIDGET_CLASS <XM_GADGET_CLASS> XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS <XM_MANAGER_WIDGET_CLASS> <XM_PRIMITIVE_WIDGET_CLASS> XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS XM_SCROLL_BAR_WIDGET_CLASS XM_SEPARATOR_GADGET_CLASS XM_SEPARATOR_WIDGET_CLASS XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS #else :XMN_HIGHLIGHT_ON_ENTER XmNhighlightOnEnter <XM_GADGET_CLASS> <XM_PRIMITIVE_WIDGET_CLASS> XM_SCALE_WIDGET_CLASS :XMN_RECOMPUTE_SIZE XmNrecomputeSize XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS :XMN_AUTOMATIC_SELECTION XmNautomaticSelection XM_LIST_WIDGET_CLASS :XMN_SHOW_SEPARATOR XmNshowSeparator XM_MAIN_WINDOW_WIDGET_CLASS :XMN_MINIMIZE_BUTTONS XmNminimizeButtons XM_MESSAGE_BOX_WIDGET_CLASS XM_SELECTION_BOX_WIDGET_CLASS :XMN_REFIGURE_MODE XmNrefigureMode XM_PANED_WINDOW_WIDGET_CLASS :XMN_SEPARATOR_ON XmNseparatorOn XM_PANED_WINDOW_WIDGET_CLASS :XMN_ALLOW_RESIZE XmNallowResize XM_PANED_WINDOW_WIDGET_CLASS :XMN_SKIP_ADJUST XmNskipAdjust XM_PANED_WINDOW_WIDGET_CLASS :XMN_FILL_ON_ARM XmNfillOnArm XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS :XMN_RESIZE_WIDTH XmNresizeWidth XM_ROW_COLUMN_WIDGET_CLASS XM_TEXT_WIDGET_CLASS XM_TEXT_FIELD_WIDGET_CLASS :XMN_RESIZE_HEIGHT XmNresizeHeight XM_ROW_COLUMN_WIDGET_CLASS XM_TEXT_WIDGET_CLASS :XMN_ADJUST_LAST XmNadjustLast XM_ROW_COLUMN_WIDGET_CLASS :XMN_IS_ALIGNED XmNisAligned XM_ROW_COLUMN_WIDGET_CLASS :XMN_ADJUST_MARGIN XmNadjustMargin XM_ROW_COLUMN_WIDGET_CLASS :XMN_RADIO_BEHAVIOR XmNradioBehavior XM_ROW_COLUMN_WIDGET_CLASS :XMN_RADIO_ALWAYS_ONE XmNradioAlwaysOne XM_ROW_COLUMN_WIDGET_CLASS :XMN_IS_HOMOGENEOUS XmNisHomogeneous XM_ROW_COLUMN_WIDGET_CLASS :XMN_POPUP_ENABLED XmNpopupEnabled XM_ROW_COLUMN_WIDGET_CLASS :XMN_SHOW_VALUE XmNshowValue XM_SCALE_WIDGET_CLASS :XMN_SHOW_ARROWS XmNshowArrows XM_SCROLL_BAR_WIDGET_CLASS :XMN_MUST_MATCH XmNmustMatch XM_SELECTION_BOX_WIDGET_CLASS :XMN_AUTO_SHOW_CURSOR_POSITION XmNautoShowCursorPosition XM_TEXT_WIDGET_CLASS :XMN_EDITABLE XmNeditable XM_TEXT_WIDGET_CLASS XM_TEXT_FIELD_WIDGET_CLASS :XMN_PENDING_DELETE XmNpendingDelete XM_TEXT_WIDGET_CLASS XM_TEXT_FIELD_WIDGET_CLASS :XMN_WORD_WRAP XmNwordWrap XM_TEXT_WIDGET_CLASS :XMN_SCROLL_VERTICAL XmNscrollVertical XM_TEXT_WIDGET_CLASS :XMN_SCROLL_HORIZONTAL XmNscrollHorizontal XM_TEXT_WIDGET_CLASS :XMN_SCROLL_LEFT_SIDE XmNscrollLeftSide XM_TEXT_WIDGET_CLASS :XMN_SCROLL_TOP_SIDE XmNscrollTopSide XM_TEXT_WIDGET_CLASS :XMN_CURSOR_POSITION_VISIBLE XmNcursorPositionVisible XM_TEXT_WIDGET_CLASS XM_TEXT_FIELD_WIDGET_CLASS :XMN_VISIBLE_WHEN_OFF XmNvisibleWhenOff XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS :XMN_SET XmNset XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS :XMN_INDICATOR_ON XmNindicatorOn XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS :XMN_FILL_ON_SELECT XmNfillOnSelect XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS #ifdef MOTIF_1.1 :XMN_DIRECTORY_VALID XmNdirectoryValid XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_VERIFY_BELL XmNverifyBell XM_TEXT_WIDGET_CLASS XM_TEXT_FIELD_WIDGET_CLASS :XMN_USE_ASYNC_GEOMETRY XmNuseAsyncGeometry <SHELL_WIDGET_CLASS> :XMN_SHOW_AS_DEFAULT XmNshowAsDefault XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS :XMN_INITIAL_RESOURCES_PERSISTENT XmNinitialResourcesPersistent <WIDGET_CLASS> #endif /* MOTIF_1.1 */ ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRButtonType [MOTIF_1.1 only] *** Type Information: One may set an XmRButtonType resource by passing a ARRAY or LIST value containing the following button-type keyword symbols: :PUSHBUTTON, :TOGGLEBUTTON, :CHECKBUTTON, :RADIOBUTTON, :CASCADEBUTTON :SEPARATOR, :DOUBLE_SEPARATOR, :TITLE. XmRButtonType is a create-time-only resource. It cannot be retrieved via :GET_VALUES. *** Resource names and the widget classes they apply to: :XMN_BUTTON_TYPE XmNbuttonType XM_ROW_COLUMN_WIDGET_CLASS (for XmCreateSimple*() routines only). #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRCallback: *** Type Information: The current version of WINTERP does not allow you to set or retrieve a widget's callback list directly. Modifications to a callback list must be done through WIDGET_CLASS methods :ADD_CALLBACK, :SET_CALLBACK, :REMOVE_ALL_CALLBACKS, or via primitive XT_REMOVE_CALLBACK. *** Resource names and the widget classes they apply to: :XMN_DESTROY_CALLBACK XmNdestroyCallback <WIDGET_CLASS> :XMN_POPUP_CALLBACK XmNpopupCallback <SHELL_WIDGET_CLASS> :XMN_POPDOWN_CALLBACK XmNpopdownCallback <SHELL_WIDGET_CLASS> :XMN_ACTIVATE_CALLBACK XmNactivateCallback XM_ARROW_BUTTON_WIDGET_CLASS XM_ARROW_BUTTON_GADGET_CLASS XM_CASCADE_BUTTON_WIDGET_CLASS XM_CASCADE_BUTTON_GADGET_CLASS XM_DRAWN_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS XM_TEXT_WIDGET_CLASS #ifdef MOTIF_1.1 XM_TEXT_FIELD_WIDGET_CLASS #endif :XMN_ARM_CALLBACK XmNarmCallback XM_ARROW_BUTTON_WIDGET_CLASS XM_ARROW_BUTTON_GADGET_CLASS XM_DRAWN_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS :XMN_DISARM_CALLBACK XmNdisarmCallback XM_ARROW_BUTTON_WIDGET_CLASS XM_ARROW_BUTTON_GADGET_CLASS XM_DRAWN_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS :XMN_FOCUS_CALLBACK XmNfocusCallback XM_BULLETIN_BOARD_WIDGET_CLASS XM_TEXT_WIDGET_CLASS :XMN_MAP_CALLBACK XmNmapCallback XM_BULLETIN_BOARD_WIDGET_CLASS XM_ROW_COLUMN_WIDGET_CLASS :XMN_UNMAP_CALLBACK XmNunmapCallback XM_BULLETIN_BOARD_WIDGET_CLASS XM_ROW_COLUMN_WIDGET_CLASS :XMN_CASCADING_CALLBACK XmNcascadingCallback XM_CASCADE_BUTTON_WIDGET_CLASS XM_CASCADE_BUTTON_GADGET_CLASS :XMN_COMMAND_ENTERED_CALLBACK XmNcommandEnteredCallback XM_COMMAND_WIDGET_CLASS :XMN_COMMAND_CHANGED_CALLBACK XmNcommandChangedCallback XM_COMMAND_WIDGET_CLASS :XMN_RESIZE_CALLBACK XmNresizeCallback XM_DRAWING_AREA_WIDGET_CLASS XM_DRAWN_BUTTON_WIDGET_CLASS :XMN_EXPOSE_CALLBACK XmNexposeCallback XM_DRAWING_AREA_WIDGET_CLASS XM_DRAWN_BUTTON_WIDGET_CLASS :XMN_INPUT_CALLBACK XmNinputCallback XM_DRAWING_AREA_WIDGET_CLASS :XMN_HELP_CALLBACK XmNhelpCallback <XM_GADGET_CLASS> <XM_MANAGER_WIDGET_CLASS> <XM_PRIMITIVE_WIDGET_CLASS> :XMN_SINGLE_SELECTION_CALLBACK XmNsingleSelectionCallback XM_LIST_WIDGET_CLASS :XMN_MULTIPLE_SELECTION_CALLBACK XmNmultipleSelectionCallback XM_LIST_WIDGET_CLASS :XMN_EXTENDED_SELECTION_CALLBACK XmNextendedSelectionCallback XM_LIST_WIDGET_CLASS :XMN_BROWSE_SELECTION_CALLBACK XmNbrowseSelectionCallback XM_LIST_WIDGET_CLASS :XMN_DEFAULT_ACTION_CALLBACK XmNdefaultActionCallback XM_LIST_WIDGET_CLASS :XMN_OK_CALLBACK XmNokCallback XM_MESSAGE_BOX_WIDGET_CLASS XM_SELECTION_BOX_WIDGET_CLASS :XMN_CANCEL_CALLBACK XmNcancelCallback XM_MESSAGE_BOX_WIDGET_CLASS XM_SELECTION_BOX_WIDGET_CLASS :XMN_ENTRY_CALLBACK XmNentryCallback XM_ROW_COLUMN_WIDGET_CLASS :XMN_VALUE_CHANGED_CALLBACK XmNvalueChangedCallback XM_SCALE_WIDGET_CLASS XM_SCROLL_BAR_WIDGET_CLASS XM_TEXT_WIDGET_CLASS XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS #ifdef MOTIF_1.1 XM_TEXT_FIELD_WIDGET_CLASS #endif :XMN_DRAG_CALLBACK XmNdragCallback XM_SCALE_WIDGET_CLASS XM_SCROLL_BAR_WIDGET_CLASS :XMN_INCREMENT_CALLBACK XmNincrementCallback XM_SCROLL_BAR_WIDGET_CLASS :XMN_DECREMENT_CALLBACK XmNdecrementCallback XM_SCROLL_BAR_WIDGET_CLASS :XMN_PAGE_INCREMENT_CALLBACK XmNpageIncrementCallback XM_SCROLL_BAR_WIDGET_CLASS :XMN_PAGE_DECREMENT_CALLBACK XmNpageDecrementCallback XM_SCROLL_BAR_WIDGET_CLASS :XMN_TO_TOP_CALLBACK XmNtoTopCallback XM_SCROLL_BAR_WIDGET_CLASS :XMN_TO_BOTTOM_CALLBACK XmNtoBottomCallback XM_SCROLL_BAR_WIDGET_CLASS :XMN_NO_MATCH_CALLBACK XmNnoMatchCallback XM_SELECTION_BOX_WIDGET_CLASS :XMN_APPLY_CALLBACK XmNapplyCallback XM_SELECTION_BOX_WIDGET_CLASS :XMN_LOSING_FOCUS_CALLBACK XmNlosingFocusCallback XM_TEXT_WIDGET_CLASS #ifdef MOTIF_1.1 XM_BULLETIN_BOARD_WIDGET_CLASS XM_TEXT_FIELD_WIDGET_CLASS #endif :XMN_MODIFY_VERIFY_CALLBACK XmNmodifyVerifyCallback XM_TEXT_WIDGET_CLASS #ifdef MOTIF_1.1 XM_TEXT_FIELD_WIDGET_CLASS #endif :XMN_MOTION_VERIFY_CALLBACK XmNmotionVerifyCallback XM_TEXT_WIDGET_CLASS #ifdef MOTIF_1.1 XM_TEXT_FIELD_WIDGET_CLASS #endif #ifdef MOTIF_1.1 :XMN_GAIN_PRIMARY_CALLBACK XmNgainPrimaryCallback XM_TEXT_WIDGET_CLASS XM_TEXT_FIELD_WIDGET_CLASS :XMN_LOSE_PRIMARY_CALLBACK XmNlosePrimaryCallback XM_TEXT_WIDGET_CLASS XM_TEXT_FIELD_WIDGET_CLASS :XMN_FOCUS_MOVED_CALLBACK XmNfocusMovedCallback <SHELL_WIDGET_CLASS> :XMN_REALIZE_CALLBACK XmNrealizeCallback <SHELL_WIDGET_CLASS> #endif /* MOTIF 1.1 */ ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRCommandWindowLocation: [MOTIF 1.1 only] *** Type Information: Resource representation type XmRCommandWindowLocation corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :COMMAND_ABOVE_WORKSPACE XmCOMMAND_ABOVE_WORKSPACE :COMMAND_BELOW_WORKSPACE XmCOMMAND_BELOW_WORKSPACE You may also specify a STRING value which will be automatically converted to XmRCommandWindowLocation by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_COMMAND_WINDOW_LOCATION XmNcommandWindowLocation XM_MAIN_WINDOW_WIDGET_CLASS #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRChar (Motif 1.0) // XmRKeySym (Motif 1.1) *** Type Information: Resource representation type XmRChar/XmRKeySym corresponds to the WINTERP-Lisp type CHARACTER. You may also specify a STRING value which will be automatically converted to XmRChar/XmRKeySym by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_MNEMONIC XmNmnemonic XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS XM_ROW_COLUMN_WIDGET_CLASS #ifdef MOTIF_1.1 :XMN_OPTION_MNEMONIC XmNoptionMnemonic <XM_ROW_COLUMN_WIDGET_CLASS created w/ :SIMPLE_OPTION_MENU> #endif /* MOTIF_1.1 */ ______________________________________________________________________________ #ifdef MOTIF_1.0 ** XmRDimension: [MOTIF 1.0 only] *** Type Information: Resource representation type XmRDimension corresponds to WINTERP-Lisp type FIXNUM, and further restricts that type to the subrange of non-negative integers. You may also specify a STRING value which will be automatically converted to XmRDimension by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_SPACING XmNspacing XM_PANED_WINDOW_WIDGET_CLASS XM_ROW_COLUMN_WIDGET_CLASS XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS Note -- Motif 1.0 has a bug in that :XMN_SPACING is inconsistently declared across widget classes. In XM_ROW_COLUMN_WIDGET_CLASS, it is declared as XmRDimension; in XM_TOGGLE_BUTTON_WIDGET_CLASS and XM_TOGGLE_BUTTON_GADGET_CLASS it is declared as XmRShort; and it's declared as XmRInt in XM_PANED_WINDOW_WIDGET_CLASS. Note that in some architectures, this may result in the bug of bogus retrieval and/or setting of values.... :XMN_WIDTH XmNwidth <WIDGET_CLASS> :XMN_HEIGHT XmNheight <WIDGET_CLASS> :XMN_BORDER_WIDTH XmNborderWidth <WIDGET_CLASS> <XM_GADGET_CLASS> <XM_MANAGER_WIDGET_CLASS> <XM_PRIMITIVE_WIDGET_CLASS> :XMN_SASH_WIDTH XmNsashWidth XM_PANED_WINDOW_WIDGET_CLASS :XMN_SASH_HEIGHT XmNsashHeight XM_PANED_WINDOW_WIDGET_CLASS :XMN_RCMARGIN_WIDTH XmNmarginWidth XM_ROW_COLUMN_WIDGET_CLASS Note -- :XMN_RCMARGIN_WIDTH is an alias for XmNmarginWidth for the Motif Row Column Widget. Motif 1.0 has a bug in that it inconsistently declares XmNmarginWidth as 'short' in a number of widget classes, but uses 'unsigned int' for the rowcolumn widget. On some architectures, this may cause method :get_values to retrieve garbage. :XMN_RCMARGIN_HEIGHT XmNmarginHeight XM_ROW_COLUMN_WIDGET_CLASS Note -- :XMN_RCMARGIN_HEIGHT is an alias for XmNmarginHeight for the Motif Row Column Widget. Motif 1.0 has a bug in that it inconsistently declares XmNmarginHeight as 'short' in a number of widget classes, but uses 'unsigned int' for the rowcolumn widget. On some architectures, this may cause method :get_values to retrieve garbage. :XMN_ENTRY_BORDER XmNentryBorder XM_ROW_COLUMN_WIDGET_CLASS :XMN_SCALE_WIDTH XmNscaleWidth XM_SCALE_WIDGET_CLASS :XMN_SCALE_HEIGHT XmNscaleHeight XM_SCALE_WIDGET_CLASS #endif /* Motif 1.0 */ ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRHorizontalDimension: [MOTIF 1.1 only] *** Type Information: Resource representation type XmRHorizontalDimension corresponds to WINTERP-Lisp type FIXNUM, and further restricts that type to the subrange of non-negative integers. If you specify a string as the value of an XmRHorizontalDimension, Motif 1.1 will automatically convert the string to a vertical axis dimension using Motif's "resolution independence" capabilities. For more information on resolution independence, see the :XMN_UNIT_TYPE (XmNunitType) resource description in the manual pages for XmGadget(3X), XmManager(3X), and XmPrimitive(3X). Also see the :XMN_SHELL_UNIT_TYPE (XmNshellUnitType) resource description in VendorShell(3X). *** Resource names and the widget classes they apply to: :XMN_SPACING XmNspacing XM_SCROLLED_WINDOW_WIDGET_CLASS XM_PANED_WINDOW_WIDGET_CLASS XM_ROW_COLUMN_WIDGET_CLASS XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS Note -- Motif 1.1 inconsistently declares resource XmNspacing: XmRDimension -- Xm/ScrolledW.c XmRHorizontalDimension -- Xm/RowColumn.c Xm/ToggleB.c Xm/ToggleBG.c XmRVerticalDimension -- Xm/PanedW.c In WINTERP, XmNspacing is treated as XmRHorizontalDimension for all widget classes. If you call :set_values :XMN_SPACING on a XM_SCROLLED_WINDOW_WIDGET_CLASS or XM_PANED_WINDOW_WIDGET_CLASS instance, note that when you give string argument as a resource value the string will be converted in terms of the current horizontal-dimension resolution-independence settings. For these cases, if you want resolution independent conversions, you must set this resource directly via ~/.Xdefaults, xrdb(1), etc. Alternately, just don't ask for resolution-independent conversions through WINTERP by specifying FIXNUM values to the problem resources. :XMN_SHADOW_THICKNESS XmNshadowThickness <GADGET_CLASS> <PRIMITIVE_WIDGET_CLASS> <MANAGER_WIDGET_CLASS> XM_DRAWN_BUTTON_WIDGET_CLASS XM_SCROLLED_WINDOW_WIDGET_CLASS XM_BULLETIN_BOARD_WIDGET_CLASS XM_ROW_COLUMN_WIDGET_CLASS XM_CASCADE_BUTTON_WIDGET_CLASS XM_CASCADE_BUTTON_GADGET_CLASS XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS :XMN_HIGHLIGHT_THICKNESS XmNhighlightThickness <GADGET_CLASS> <PRIMITIVE_WIDGET_CLASS> XM_CASCADE_BUTTON_WIDGET_CLASS XM_CASCADE_BUTTON_GADGET_CLASS XM_DRAWN_BUTTON_WIDGET_CLASS XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS XM_SCALE_WIDGET_CLASS XM_SCROLL_BAR_WIDGET_CLASS XM_SEPARATOR_WIDGET_CLASS XM_SEPARATOR_GADGET_CLASS XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS :XMN_HORIZONTAL_SPACING XmNhorizontalSpacing XM_FORM_WIDGET_CLASS :XMN_WIDTH XmNwidth <SHELL_WIDGET_CLASS> <GADGET_CLASS> <PRIMITIVE_CLASS> <MANAGER_CLASS> XM_SCALE_WIDGET_CLASS :XMN_BORDER_WIDTH XmNborderWidth <SHELL_WIDGET_CLASS> <WIDGET_CLASS> <GADGET_CLASS> <PRIMITIVE_CLASS> <MANAGER_CLASS> :XMN_MARGIN_LEFT XmNmarginLeft XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS :XMN_MARGIN_RIGHT XmNmarginRight XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS :XMN_LIST_MARGIN_WIDTH XmNlistMarginWidth XM_LIST_WIDGET_CLASS :XMN_MAIN_WINDOW_MARGIN_WIDTH XmNmainWindowMarginWidth XM_MAIN_WINDOW_MARGIN_WIDTH :XMN_SASH_WIDTH XmNsashWidth XM_PANED_WINDOW_WIDGET_CLASS :XMN_SASH_SHADOW_THICKNESS XmNsashShadowThickness XM_PANED_WINDOW_WIDGET_CLASS :XMN_DEFAULT_BUTTON_SHADOW_THICKNESS XmNdefaultButtonShadowThickness XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS :XMN_ENTRY_BORDER XmNentryBorder XM_ROW_COLUMN_WIDGET_CLASS :XMN_SCALE_WIDTH XmNscaleWidth XM_SCALE_WIDGET_CLASS :XMN_SCROLLED_WINDOW_MARGIN_WIDTH XmNscrolledWindowMarginWidth XM_SCROLLED_WINDOW_WIDGET_CLASS :XMN_MARGIN XmNmargin #endif /* MOTIF_1.1 */ ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRVerticalDimension: [MOTIF 1.1 only] *** Type Information: Resource representation type XmRVerticalDimension corresponds to WINTERP-Lisp type FIXNUM, and further restricts that type to the subrange of non-negative integers. If you specify a string as the value of an XmRVerticalDimension, Motif 1.1 will automatically convert the string to a vertical axis dimension using Motif's "resolution independence" capabilities. For more information on resolution independence, see the :XMN_UNIT_TYPE (XmNunitType) resource description in the manual pages for XmGadget(3X), XmManager(3X), and XmPrimitive(3X). Also see the :XMN_SHELL_UNIT_TYPE (XmNshellUnitType) resource description in VendorShell(3X). *** Resource names and the widget classes they apply to: :XMN_HEIGHT XmNheight <WIDGET_CLASS> <SHELL_WIDGET_CLASS> Note -- Motif 1.1 inconsistently declares resource XmNheight: XmRShellVertDim -- Xm/Vendor.c XtRDimension -- Xt/RectObj.c XmRVerticalDimension -- Xm/Gadget.c Xm/Manager.c Xm/Primitive.c Xm/Scale.c :XMN_MARGIN_HEIGHT XmNmarginHeight XM_BULLETIN_BOARD_WIDGET_CLASS XM_DRAWING_AREA_WIDGET_CLASS XM_FORM_WIDGET_CLASS XM_FRAME_WIDGET_CLASS XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS XM_PANED_WIDGET_CLASS XM_ROW_COLUMN_WIDGET_CLASS XM_TEXT_WIDGET_CLASS XM_TEXT_FIELD_WIDGET_CLASS :XMN_VERTICAL_SPACING XmNverticalSpacing XM_FORM_WIDGET_CLASS :XMN_MARGIN_TOP XmNmarginTop XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS :XMN_MARGIN_BOTTOM XmNmarginBottom XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS :XMN_LIST_SPACING XmNlistSpacing XM_LIST_WIDGET_CLASS :XMN_LIST_MARGIN_HEIGHT XmNlistMarginHeight XM_LIST_WIDGET_CLASS :XMN_MAIN_WINDOW_MARGIN_HEIGHT XmNmainWindowMarginHeight XM_MAIN_WINDOW_WIDGET_CLASS :XMN_SASH_HEIGHT XmNsashHeight XM_PANED_WIDGET_CLASS :XMN_PANE_MINIMUM XmNpaneMinimum XM_PANED_WIDGET_CLASS :XMN_PANE_MAXIMUM XmNpaneMaximum XM_PANED_WIDGET_CLASS :XMN_SCALE_HEIGHT XmNscaleHeight XM_SCALE_WIDGET_CLASS :XMN_SCROLLED_WINDOW_MARGIN_HEIGHT XmNscrolledWindowMarginHeight XM_SCROLLED_WINDOW_WIDGET_CLASS :XMN_INDICATOR_SIZE XmNindicatorSize XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRDefaultButtonType: *** Type Information: Resource representation type XmRDefaultButtonType corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :DIALOG_OK_BUTTON XmDIALOG_OK_BUTTON :DIALOG_CANCEL_BUTTON XmDIALOG_CANCEL_BUTTON :DIALOG_HELP_BUTTON XmDIALOG_HELP_BUTTON You may also specify a STRING value which will be automatically converted to XmRDefaultButtonType by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_DEFAULT_BUTTON_TYPE XmNdefaultButtonType XM_MESSAGE_BOX_WIDGET_CLASS ______________________________________________________________________________ ** XmRDeleteResponse: *** Type Information: Resource representation type XmRDeleteResponse corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :DESTROY XmDESTROY :UNMAP XmUNMAP :DO_NOTHING XmDO_NOTHING You may also specify a STRING value which will be automatically converted to XmRDeleteResponse by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_DELETE_RESPONSE XmNdeleteResponse <SHELL_WIDGET_CLASS> XM_DIALOG_POPUP_SHELL_WIDGET_CLASS ______________________________________________________________________________ ** XmRDialogStyle: *** Type Information: Resource representation type XmRDialogStyle corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: #ifdef MOTIF_1.0 :DIALOG_WORK_AREA XmDIALOG_WORK_AREA :DIALOG_MODELESS XmDIALOG_MODELESS :DIALOG_APPLICATION_MODAL XmDIALOG_APPLICATION_MODAL :DIALOG_SYSTEM_MODAL XmDIALOG_SYSTEM_MODAL #endif #ifdef MOTIF_1.1 :DIALOG_MODELESS XmDIALOG_MODELESS :DIALOG_PRIMARY_APPLICATION_MODAL XmDIALOG_PRIMARY_APPLICATION_MODAL :DIALOG_FULL_APPLICATION_MODAL XmDIALOG_FULL_APPLICATION_MODAL :DIALOG_SYSTEM_MODAL XmDIALOG_SYSTEM_MODAL Note 1: XmRDialogStyle value :DIALOG_APPLICATION_MODAL from Motif 1.0 is obsolete, use :DIALOG_PRIMARY_APPLICATION_MODAL instead. Note 2: XmRDialogStyle value :DIALOG_WORK_AREA cannot be retrieved by WINTERP due to Motif 1.1 bug: enumeration XmDIALOG_WORK_AREA has same value (0) as XmDIALOG_MODELESS which means that if you set :DIALOG_WORK_AREA, method :GET_VALUES will retrieve :DIALOG_MODELESS (due to ordering...) #endif You may also specify a STRING value which will be automatically converted to XmRDialogStyle by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_DIALOG_STYLE XmNdialogStyle XM_BULLETIN_BOARD_WIDGET_CLASS ______________________________________________________________________________ ** XmRDialogType: *** Type Information: Resource representation type XmRDialogType corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :DIALOG_ERROR XmDIALOG_ERROR :DIALOG_INFORMATION XmDIALOG_INFORMATION :DIALOG_MESSAGE XmDIALOG_MESSAGE :DIALOG_QUESTION XmDIALOG_QUESTION :DIALOG_WARNING XmDIALOG_WARNING :DIALOG_WORKING XmDIALOG_WORKING :DIALOG_PROMPT XmDIALOG_PROMPT :DIALOG_SELECTION XmDIALOG_SELECTION :DIALOG_COMMAND XmDIALOG_COMMAND You may also specify a STRING value which will be automatically converted to XmRDialogType by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. #ifdef MOTIF_1.1 Note that Motif 1.1 introduced a new bug which makes it impossible to do a :GET_VALUES of a XmRDialogType resource and retrieve values :DIALOG_PROMPT, :DIALOG_SELECTION, or :DIALOG_COMMAND. Even if you did a :SET_VALUES of an XmRDialogType resource to :DIALOG_PROMPT, :DIALOG_SELECTION, or :DIALOG_COMMAND, method :GET_VALUES will return: :DIALOG_ERROR for :DIALOG_PROMPT :DIALOG_INFORMATION for :DIALOG_SELECTION :DIALOG_MESSAGE for :DIALOG_COMMAND And that of course means that values set and then retrieved from an XmRDialogType resource will not necessary be EQ. #endif *** Resource names and the widget classes they apply to: :XMN_DIALOG_TYPE XmNdialogType XM_COMMAND_WIDGET_CLASS XM_FILE_SELECTION_BOX_WIDGET_CLASS XM_MESSAGE_BOX_WIDGET_CLASS XM_SELECTION_BOX_WIDGET_CLASS ______________________________________________________________________________ ** XmREditMode: *** Type Information: Resource representation type XmREditMode corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :MULTI_LINE_EDIT XmMULTI_LINE_EDIT :SINGLE_LINE_EDIT XmSINGLE_LINE_EDIT *** Resource names and the widget classes they apply to: :XMN_EDIT_MODE XmNeditMode XM_TEXT_WIDGET_CLASS ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRFileTypeMask: [MOTIF 1.1 only] *** Type Information: Resource representation type XmRFileTypeMask corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :FILE_DIRECTORY XmFILE_DIRECTORY :FILE_REGULAR XmFILE_REGULAR :FILE_ANY_TYPE XmFILE_ANY_TYPE *** Resource names and the widget classes they apply to: :XMN_FILE_TYPE_MASK XmNfileTypeMask XM_FILE_SELECTION_BOX_WIDGET_CLASS #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRFontList: *** Type Information: The current version of WINTERP does not allow you to get a widget's XmRFontList value since WINTERP-Lisp doesn't currently support XmRFontList as a type. Adding this type was not a high priority in this first release of WINTERP; I expect to add it in a subsequent release along with various XmString utilities that use the XmFontList type. One may set a XmRFontList resource by specifying a STRING value corresponding to the font's name. These string values will then get looked up using Motif's font-searching and font-cacheing utilities. You may specify any value that you would specify to a XmRFontList resource in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_BUTTON_FONT_LIST XmNbuttonFontList XM_BULLETIN_BOARD_WIDGET_CLASS :XMN_LABEL_FONT_LIST XmNlabelFontList XM_BULLETIN_BOARD_WIDGET_CLASS :XMN_TEXT_FONT_LIST XmNtextFontList XM_BULLETIN_BOARD_WIDGET_CLASS :XMN_FONT_LIST XmNfontList XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS XM_LIST_WIDGET_CLASS XM_SCALE_WIDGET_CLASS XM_TEXT_WIDGET_CLASS #ifdef MOTIF_1.1 XM_TEXT_FIELD_WIDGET_CLASS #endif /* MOTIF_1.1 #ifdef MOTIF_1.1 :XMN_DEFAULT_FONT_LIST XmNdefaultFontList <SHELL_WIDGET_CLASS> XM_MENU_POPUP_SHELL_WIDGET_CLASS #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRIndicatorType: *** Type Information: Resource representation type XmRIndicatorType corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :N_OF_MANY XmN_OF_MANY :ONE_OF_MANY XmONE_OF_MANY You may also specify a STRING value which will be automatically converted to XmRIndicatorType by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_INDICATOR_TYPE XmNindicatorType XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRInitialState: [MOTIF 1.1 only] *** Type Information: Resource representation type XtRInitialState/XmRInitialState corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp this type and their associated X11/Motif constants: :WITHDRAWN_STATE WithdrawnState :NORMAL_STATE NormalState :ICONIC_STATE IconicState *** Resource names and the widget classes they apply to: :XMN_INITIAL_STATE XmNinitialState <SHELL_WIDGET_CLASS> <POPUP_SHELL_WIDGET_CLASS> #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRInt: *** Type Information: Resource representation type XmRInt corresponds to WINTERP-Lisp type FIXNUM. On architectures where the range of type 'long' is different from the range of type 'int', FIXNUM values exceeding the minimum and maximum 'int' limits will cause XLISP to signal an error. *** Resource names and the widget classes they apply to: :XMN_MAPPING_DELAY XmNmappingDelay XM_CASCADE_BUTTON_WIDGET_CLASS XM_CASCADE_BUTTON_GADGET_CLASS :XMN_HISTORY_ITEM_COUNT XmNhistoryItemCount XM_COMMAND_WIDGET_CLASS :XMN_HISTORY_MAX_ITEMS XmNhistoryMaxItems XM_COMMAND_WIDGET_CLASS :XMN_HISTORY_VISIBLE_ITEM_COUNT XmNhistoryVisibleItemCount XM_COMMAND_WIDGET_CLASS :XMN_FRACTION_BASE XmNfractionBase XM_FORM_WIDGET_CLASS :XMN_TOP_POSITION XmNtopPosition Any <WIDGET_CLASS> that has XM_FORM_WIDGET_CLASS constraints. #ifdef MOTIF_1.0 XM_TEXT_WIDGET_CLASS (name changed to XmNtopCharacter in 1.1) #endif /* MOTIF_1.0 */ :XMN_BOTTOM_POSITION XmNbottomPosition Any <WIDGET_CLASS> that has XM_FORM_WIDGET_CLASS constraints. :XMN_LEFT_POSITION XmNleftPosition Any <WIDGET_CLASS> that has XM_FORM_WIDGET_CLASS constraints. :XMN_RIGHT_POSITION XmNrightPosition Any <WIDGET_CLASS> that has XM_FORM_WIDGET_CLASS constraints. :XMN_TOP_OFFSET XmNtopOffset Any <WIDGET_CLASS> that has XM_FORM_WIDGET_CLASS constraints. :XMN_BOTTOM_OFFSET XmNbottomOffset Any <WIDGET_CLASS> that has XM_FORM_WIDGET_CLASS constraints. :XMN_LEFT_OFFSET XmNleftOffset Any <WIDGET_CLASS> that has XM_FORM_WIDGET_CLASS constraints. :XMN_RIGHT_OFFSET XmNrightOffset Any <WIDGET_CLASS> that has XM_FORM_WIDGET_CLASS constraints. :XMN_ITEM_COUNT XmNitemCount XM_LIST_WIDGET_CLASS :XMN_SELECTED_ITEM_COUNT XmNselectedItemCount XM_LIST_WIDGET_CLASS :XMN_VISIBLE_ITEM_COUNT XmNvisibleItemCount XM_LIST_WIDGET_CLASS :XMN_DOUBLE_CLICK_INTERVAL XmNdoubleClickInterval XM_LIST_WIDGET_CLASS :XMN_VALUE XmNvalue XM_SCALE_WIDGET_CLASS XM_SCROLL_BAR_WIDGET_CLASS Note -- resource name :XMN_VALUE will not set or retrieve a string value in XM_TEXT_WIDGET_CLASS instances. Motif 1.0 & 1.1 has a bug that inconsistently declares the value associated with the "message" XmNvalue as 'int' for XM_SCALE_WIDGET_CLASS XM_SCROLL_BAR_WIDGET_CLASS, and as a 'string' for the text widget. Thus, to retrieve or set the string in a text widget, use the alias resource name :XMN_STRING. :XMN_MAXIMUM XmNmaximum XM_SCALE_WIDGET_CLASS XM_SCROLL_BAR_WIDGET_CLASS #ifdef MOTIF_1.0 XM_PANED_WINDOW_WIDGET_CLASS #else For Motif 1.1's XM_PANED_WINDOW_WIDGET_CLASS, :XMN_MAXIMUM has been changed to :XMN_PANE_MAXIMUM. #endif /* MOTIF_1.0 */ :XMN_MINIMUM XmNminimum XM_SCALE_WIDGET_CLASS XM_SCROLL_BAR_WIDGET_CLASS #ifdef MOTIF_1.0 XM_PANED_WINDOW_WIDGET_CLASS #else For Motif 1.1's XM_PANED_WINDOW_WIDGET_CLASS, :XMN_MINIMUM has been changed to :XMN_PANE_MINIMUM. #endif /* MOTIF_1.0 */ :XMN_SLIDER_SIZE XmNsliderSize XM_SCROLL_BAR_WIDGET_CLASS :XMN_INCREMENT XmNincrement XM_SCROLL_BAR_WIDGET_CLASS :XMN_PAGE_INCREMENT XmNpageIncrement XM_SCROLL_BAR_WIDGET_CLASS :XMN_INITIAL_DELAY XmNinitialDelay XM_SCROLL_BAR_WIDGET_CLASS :XMN_REPEAT_DELAY XmNrepeatDelay XM_SCROLL_BAR_WIDGET_CLASS :XMN_LIST_ITEM_COUNT XmNlistItemCount XM_SELECTION_BOX_WIDGET_CLASS :XMN_LIST_VISIBLE_ITEM_COUNT XmNlistVisibleItemCount XM_SELECTION_BOX_WIDGET_CLASS :XMN_MAX_LENGTH XmNmaxLength XM_TEXT_WIDGET_CLASS #ifdef MOTIF_1.1 XM_TEXT_FIELD_WIDGET_CLASS #endif /* MOTIF_1.1 */ :XMN_BLINK_RATE XmNblinkRate XM_TEXT_WIDGET_CLASS #ifdef MOTIF_1.1 XM_TEXT_FIELD_WIDGET_CLASS #endif /* MOTIF_1.1 */ :XMN_SELECTION_ARRAY_COUNT XmNselectionArrayCount XM_TEXT_WIDGET_CLASS #ifdef MOTIF_1.1 XM_TEXT_FIELD_WIDGET_CLASS #endif /* MOTIF_1.1 */ :XMN_SELECT_THRESHOLD XmNselectThreshold XM_TEXT_WIDGET_CLASS #ifdef MOTIF_1.1 XM_TEXT_FIELD_WIDGET_CLASS #endif /* MOTIF_1.1 */ :XMN_MWM_DECORATIONS XmNmwmDecorations <SHELL_WIDGET_CLASS> Note: The value supplied or retrieved via resource :XMN_MWM_DECORATIONS is a FIXNUM mask that can be created by doing the logical inclusive or (see function 'logior') of the following symbol's values: MWM_DECOR_ALL MWM_DECOR_BORDER MWM_DECOR_RESIZEH MWM_DECOR_TITLE MWM_DECOR_MENU MWM_DECOR_MINIMIZE MWM_DECOR_MAXIMIZE :XMN_MWM_FUNCTIONS XmNmwmFunctions <SHELL_WIDGET_CLASS> Note: The value supplied or retrieved via resource :XMN_MWM_FUNCTIONS is a FIXNUM mask that can be created by doing the logical inclusive or (see function 'logior') of the following symbol's values: MWM_FUNC_ALL MWM_FUNC_RESIZE MWM_FUNC_MOVE MWM_FUNC_MINIMIZE MWM_FUNC_MAXIMIZE MWM_FUNC_CLOSE :XMN_MWM_INPUT_MODE XmNmwmInputMode <SHELL_WIDGET_CLASS> Note: The value supplied or retrieved via resource :XMN_MWM_INPUT_MODE is a FIXNUM mask that can be created by doing the logical inclusive or (see function 'logior') of the following symbol's values: #ifdef MOTIF_1.1 MWM_INPUT_MODELESS MWM_INPUT_PRIMARY_APPLICATION_MODAL MWM_INPUT_SYSTEM_MODAL MWM_INPUT_FULL_APPLICATION_MODAL #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.0 MWM_INPUT_MODELESS MWM_INPUT_APPLICATION_MODAL MWM_INPUT_SYSTEM_MODAL #endif :XMN_DEPTH XmNdepth <SHELL_WIDGET_CLASS> <WIDGET_CLASS> :XMN_WM_TIMEOUT XmNwmTimeout <SHELL_WIDGET_CLASS> #ifdef MOTIF_1.1 :XMN_DIR_LIST_ITEM_COUNT XmNdirListItemCount XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_FILE_LIST_ITEM_COUNT XmNfileListItemCount XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_TOP_ITEM_POSITION XmNtopItemPosition XM_LIST_WIDGET_CLASS :XMN_POST_FROM_COUNT XmNpostFromCount XM_ROW_COLUMN_WIDGET_CLASS :XMN_SCALE_MULTIPLE XmNscaleMultiple XM_SCALE_WIDGET_CLASS :XMN_BUTTON_COUNT XmNbuttonCount <XM_ROW_COLUMN_WIDGET_CLASS created w/ :SIMPLE_*> :XMN_POST_FROM_BUTTON XmNpostFromButton <XM_ROW_COLUMN_WIDGET_CLASS created w/ :SIMPLE_*> :XMN_BUTTON_SET XmNbuttonSet <XM_ROW_COLUMN_WIDGET_CLASS created w/ :SIMPLE_*> #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.0 :XMN_MIN_WIDTH XmNminWidth <SHELL_WIDGET_CLASS> :XMN_MAX_WIDTH XmNmaxWidth <SHELL_WIDGET_CLASS> :XMN_MIN_HEIGHT XmNminHeight <SHELL_WIDGET_CLASS> :XMN_MAX_HEIGHT XmNmaxHeight <SHELL_WIDGET_CLASS> :XMN_WIDTH_INC XmNwidthInc <SHELL_WIDGET_CLASS> :XMN_HEIGHT_INC XmNheightInc <SHELL_WIDGET_CLASS> :XMN_MIN_ASPECT_X XmNminAspectX <SHELL_WIDGET_CLASS> :XMN_MIN_ASPECT_Y XmNminAspectY <SHELL_WIDGET_CLASS> :XMN_MAX_ASPECT_X XmNmaxAspectX <SHELL_WIDGET_CLASS> :XMN_MAX_ASPECT_Y XmNmaxAspectY <SHELL_WIDGET_CLASS> #ifdef MOTIF_1.0 :XMN_INITIAL_STATE XmNinitialState <SHELL_WIDGET_CLASS> #else Note: In Motif 1.1, :XMN_INITIAL_STATE is an enumerated type, see section on resource representation type XtRInitialState. #endif /* MOTIF_1.0 */ :XMN_ICON_X XmNiconX <SHELL_WIDGET_CLASS> :XMN_ICON_Y XmNiconY <SHELL_WIDGET_CLASS> :XMN_HORIZONTAL_SPACING XmNhorizontalSpacing XM_FORM_WIDGET_CLASS :XMN_VERTICAL_SPACING XmNverticalSpacing XM_FORM_WIDGET_CLASS :XMN_SASH_SHADOW_THICKNESS XmNsashShadowThickness XM_PANED_WINDOW_WIDGET_CLASS :XMN_CURSOR_POSITION XmNcursorPosition XM_TEXT_WIDGET_CLASS #endif /* MOTIF 1.0 */ ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRHorizontalInt: [MOTIF 1.1 only] *** Type Information: Resource representation type XmRHorizontalInt corresponds to WINTERP-Lisp type FIXNUM. On architectures where the range of type 'long' is different from the range of type 'int', FIXNUM values exceeding the minimum and maximum 'int' limits will cause XLISP to signal an error. If you specify a string as the value of an XmRHorizontalInt, Motif 1.1 will automatically convert the string to a horizontal axis size or position using Motif's "resolution independence" capabilities. For more information on resolution independence, see the :XMN_UNIT_TYPE (XmNunitType) resource description in the manual pages for XmGadget(3X), XmManager(3X), and XmPrimitive(3X). Also see the :XMN_SHELL_UNIT_TYPE (XmNshellUnitType) resource description in VendorShell(3X). *** Resource names and the widget classes they apply to: :XMN_BASE_WIDTH XmNbaseWidth <SHELL_WIDGET_CLASS> :XMN_MIN_WIDTH XmNminWidth <SHELL_WIDGET_CLASS> :XMN_MAX_WIDTH XmNmaxWidth <SHELL_WIDGET_CLASS> :XMN_WIDTH_INC XmNwidthInc <SHELL_WIDGET_CLASS> :XMN_MIN_ASPECT_X XmNminAspectX <SHELL_WIDGET_CLASS> :XMN_MAX_ASPECT_X XmNmaxAspectX <SHELL_WIDGET_CLASS> :XMN_ICON_X XmNiconX <SHELL_WIDGET_CLASS> #endif /* MOTIF_1.1 */ ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRVerticalInt: [MOTIF 1.1 only] *** Type Information: Resource representation type XmRVerticalInt corresponds to WINTERP-Lisp type FIXNUM. On architectures where the range of type 'long' is different from the range of type 'int', FIXNUM values exceeding the minimum and maximum 'int' limits will cause XLISP to signal an error. If you specify a string as the value of an XmRVerticalInt, Motif 1.1 will automatically convert the string to a vertical axis size or position using Motif's "resolution independence" capabilities. For more information on resolution independence, see the :XMN_UNIT_TYPE (XmNunitType) resource description in the manual pages for XmGadget(3X), XmManager(3X), and XmPrimitive(3X). Also see the :XMN_SHELL_UNIT_TYPE (XmNshellUnitType) resource description in VendorShell(3X). *** Resource names and the widget classes they apply to: :XMN_BASE_HEIGHT XmNbaseHeight <SHELL_WIDGET_CLASS> :XMN_MIN_HEIGHT XmNminHeight <SHELL_WIDGET_CLASS> :XMN_MAX_HEIGHT XmNmaxHeight <SHELL_WIDGET_CLASS> :XMN_HEIGHT_INC XmNheightInc <SHELL_WIDGET_CLASS> :XMN_MIN_ASPECT_Y XmNminAspectY <SHELL_WIDGET_CLASS> :XMN_MAX_ASPECT_Y XmNmaxAspectY <SHELL_WIDGET_CLASS> :XMN_ICON_Y XmNiconY <SHELL_WIDGET_CLASS> #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRKeyboardFocusPolicy: *** Type Information: Resource representation type XmRKeyboardFocusPolicy corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :EXPLICIT XmEXPLICIT :POINTER XmPOINTER You may also specify a STRING value which will be automatically converted to XmRKeyboardFocusPolicy by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_KEYBOARD_FOCUS_POLICY XmNkeyboardFocusPolicy <SHELL_WIDGET_CLASS> <POPUP_SHELL_WIDGET_CLASS> ______________________________________________________________________________ ** XmRLabelType: *** Type Information: Resource representation type XmRLabelType corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :PIXMAP XmPIXMAP :STRING XmSTRING You may also specify a STRING value which will be automatically converted to XmRLabelType by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_LABEL_TYPE XmNlabelType XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS ______________________________________________________________________________ ** XmRListSizePolicy: *** Type Information: Resource representation type XmRListSizePolicy corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :VARIABLE XmVARIABLE :CONSTANT XmCONSTANT :RESIZE_IF_POSSIBLE XmRESIZE_IF_POSSIBLE You may also specify a STRING value which will be automatically converted to XmRListSizePolicy by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_LIST_SIZE_POLICY XmNlistSizePolicy XM_LIST_WIDGET_CLASS ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRMultiClick: [Motif 1.1 only] *** Type Information: Resource representation type XmRMultiClick corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :MULTICLICK_DISCARD XmMULTICLICK_DISCARD :MULTICLICK_KEEP XmMULTICLICK_KEEP You may also specify a STRING value which will be automatically converted to XmRMultiClick by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_MULTI_CLICK XmNmultiClick XM_ARROW_BUTTON_WIDGET_CLASS XM_ARROW_BUTTON_GADGET_CLASS XM_DRAWN_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS #endif /* MOTIF_1.1 */ ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRNavigationType: [Motif 1.1 only] *** Type Information: Resource representation type XmRNavigationType corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :NONE XmNONE :TAB_GROUP XmTAB_GROUP :STICKY_TAB_GROUP XmSTICKY_TAB_GROUP :EXCLUSIVE_TAB_GROUP XmEXCLUSIVE_TAB_GROUP You may also specify a STRING value which will be automatically converted to XmRNavigationType by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_NAVIGATION_TYPE XmNnavigationType <GADGET_CLASS> <MANAGER_CLASS> <PRIMITIVE_CLASS> XM_LIST_WIDGET_CLASS XM_MAIN_WINDOW_WIDGET_CLASS XM_ROW_COLUMN_WIDGET_CLASS XM_SCROLL_BAR_WIDGET_CLASS XM_TEXT_WIDGET_CLASS XM_TEXT_FIELD_WIDGET_CLASS #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmROrientation: *** Type Information: Resource representation type XmROrientation corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :NO_ORIENTATION XmNO_ORIENTATION :VERTICAL XmVERTICAL :HORIZONTAL XmHORIZONTAL You may also specify a STRING value which will be automatically converted to XmROrientation by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_ORIENTATION XmNorientation XM_ROW_COLUMN_WIDGET_CLASS XM_SCALE_WIDGET_CLASS XM_SCROLL_BAR_WIDGET_CLASS XM_SEPARATOR_GADGET_CLASS XM_SEPARATOR_WIDGET_CLASS ______________________________________________________________________________ ** XmRPacking: *** Type Information: Resource representation type XmRPacking corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :NO_PACKING XmNO_PACKING :PACK_TIGHT XmPACK_TIGHT :PACK_COLUMN XmPACK_COLUMN :PACK_NONE XmPACK_NONE You may also specify a STRING value which will be automatically converted to XmRPacking by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_PACKING XmNpacking XM_ROW_COLUMN_WIDGET_CLASS ______________________________________________________________________________ ** XmRPixel: *** Type Information: Resource representation type XmRPixel corresponds to the WINTERP-Lisp atomic type PIXEL, which is X's way of representing a color. One may set XmRPixel resources by specifying a STRING color name, just as you would in $HOME/.Xdefaults. Alternatively, one can use the result of primitive X_ALLOC_COLOR, X_STORE_COLOR/X_ALLOC_N_COLOR_CELLS_NO_PLANES, or the result of :get_values on the XmRPixel resource of another widget. *** Resource names and the widget classes they apply to: :XMN_FOREGROUND XmNforeground <MANAGER_WIDGET_CLASS> <PRIMITIVE_WIDGET_CLASS> :XMN_BACKGROUND XmNbackground <MANAGER_WIDGET_CLASS> <PRIMITIVE_WIDGET_CLASS> <WIDGET_CLASS> :XMN_HIGHLIGHT_COLOR XmNhighlightColor <MANAGER_WIDGET_CLASS> <PRIMITIVE_WIDGET_CLASS> :XMN_TOP_SHADOW_COLOR XmNtopShadowColor <MANAGER_WIDGET_CLASS> <PRIMITIVE_WIDGET_CLASS> :XMN_BOTTOM_SHADOW_COLOR XmNbottomShadowColor <MANAGER_WIDGET_CLASS> <PRIMITIVE_WIDGET_CLASS> :XMN_ARM_COLOR XmNarmColor XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS #ifdef MOTIF_1.1 :XMN_TROUGH_COLOR XmNtroughColor XM_SCROLL_BAR_WIDGET_CLASS #endif /* MOTIF_1.1 */ :XMN_SELECT_COLOR XmNselectColor XM_TOGGLE_BUTTON_WIDGET_CLASS XM_TOGGLE_BUTTON_GADGET_CLASS :XMN_BORDER_COLOR XmNborderColor <WIDGET_CLASS> ______________________________________________________________________________ ** XmRPixmap, XmRPrimForegroundPixmap, XmRManForegroundPixmap, XmRPrimHighlightPixmap, XmRManHighlightPixmap: *** Type Information: Resource representation type XmR*Pixmap corresponds to the WINTERP-Lisp atomic type PIXMAP as returned by primitive XM_GET_PIXMAP. Pixmaps are used by widgets to display graphical images. One may set Pixmap resources by specifying the STRING name of the pixmap. Pixmaps get named by "installing" an XImage with an associated name by using primitive XM_INSTALL_IMAGE. If a named pixmap cannot be found, then the pixmap name is taken as a filename for an X10 or X11 bitmap file. The pixmap name must either have a fully qualified path-name, or be on the file path specified by environment variable XBMLANGPATH, or must be in Motif's default pixmap search path. For more information, see the documentation for XmGetPixmap(X). Additionally, Motif defines the following preinstalled pixmap names: "background", "25_foreground", "50_foreground", "75_foreground", "vertical", "horizontal", "slant_right", "slant_left", "menu_cascade", and "menu_checkmark". Note that if you specify a string value for a pixmap at widget-creation time, Motif's string --> pixmap converters may retrieve the wrong colors for the pixmap -- you'll get back a pixmap using the default foreground, background, and highlight colors of *TOPLEVEL_WIDGET*. If you set a pixmap resource via :SET_VALUES, the pixmap will use the widget manager's foreground and background colors. If these default colors are not appropriate, you should set pixmap resources to the result of primitive XM_GET_PIXMAP. *** Garbage Collection of Pixmaps: Unused pixmaps are garbage collected by WINTERP -- if no references to them exist in any WIDGETOBJ or other WINTERP-XLISP variable, their server and client-side storage will get reclaimed. In other words, PIXMAPs do what you'd expect them to do in a Lispy garbage collected system. This is certainly useful and good to do because we can expect pixmaps to take up a reasonable amount of client and server space -- we should be efficient about their use, especially because Motif has made it easy to do so. Motif provides an explicit function XmDestroyPixmap() to deallocate unused pixmaps. Unfortunately, it is often difficult for a user to know when a pixmap is no longer being used. If a user calls XmDestroyPixmap() on a pixmap that is still being used by a widget, a guaranteed coredump will result due to an "X Protocol Error". Therefore, WINTERP provides no interface to XmDestroyPixmap(); instead it extends XLISP's mark/sweep garbage collector to use the reference counting and pixmap cacheing scheme of XmGetPixmap() and XmDestroyPixmap(). Unfortunately, the XImage* behind the pixmap still persists even if all pixmaps based on a particular Ximage no longer exist. Since XImages can be implicitly created inside XmGetPixmap(), or through a String-->Xm*Pixmap* conversion it will be very hard to get a hold of the actual XImage pointer when all we have access to are the name-strings of the previously installed images or the filenames of new images installed. Either we'll have to prevent creating cached XImages inside XmGetPixmap() and the XmString-->Xm*Pixmap* converters, and do all this ourselves, or we can just punt. I'm going to punt on the harder problem, and let people that care about this use the primitives XM_INSTALL_IMAGE XM_UNINSTALL_IMAGE. Rather than having XmGetPixmap() or the String-->Xm*Pixmap* converters implicitly create XImage's, you should pre-create the necessary <XImage_obj> by using XM_INSTALL_IMAGE(XM_GET_IMAGE_FROM_FILE(<image_file_name>)) at application startup time. Later, you may explicitly destroy the <XImage_obj> via primitive XM_UNINSTALL_IMAGE when the XImage is no longer needed. Destroying an XImage after creating the necessary pixmaps from it shouldn't cause any protocol errors, so this is the thing to do. *** Resource names and the widget classes they apply to: :XMN_ICON_PIXMAP XmNiconPixmap <SHELL_WIDGET_CLASS> -- XmRPixmap :XMN_ICON_MASK XmNiconMask <SHELL_WIDGET_CLASS> -- XmRPixmap :XMN_BACKGROUND_PIXMAP XmNbackgroundPixmap <WIDGET_CLASS> -- XmRPixmap <XM_MANAGER_WIDGET_CLASS> -- XmRXmBackgroundPixmap <XM_PRIMITIVE_WIDGET_CLASS> -- XmRXmBackgroundPixmap :XMN_BORDER_PIXMAP XmNborderPixmap <WIDGET_CLASS> -- XmRPixmap :XMN_LABEL_INSENSITIVE_PIXMAP XmNlabelInsensitivePixmap XM_LABEL_WIDGET_CLASS -- XmRPixmap XM_LABEL_GADGET_CLASS -- XmRGadgetPixmap :XMN_SELECT_INSENSITIVE_PIXMAP XmNselectInsensitivePixmap XM_TOGGLE_BUTTON_GADGET_CLASS -- XmRPixmap XM_TOGGLE_BUTTON_WIDGET_CLASS -- XmRGadgetPixmap :XMN_SELECT_PIXMAP XmNselectPixmap XM_TOGGLE_BUTTON_WIDGET_CLASS -- XmRPrimForegroundPixmap; XM_TOGGLE_BUTTON_GADGET_CLASS -- XmRPixmap :XMN_CASCADE_PIXMAP XmNcascadePixmap XM_CASCADE_BUTTON_WIDGET_CLASS -- XmRPrimForegroundPixmap XM_CASCADE_BUTTON_GADGET_CLASS -- XmRGadgetPixmap :XMN_LABEL_PIXMAP XmNlabelPixmap XM_LABEL_WIDGET_CLASS -- XmRPrimForegroundPixmap XM_LABEL_GADGET_CLASS -- XmRManForegroundPixmap :XMN_HIGHLIGHT_PIXMAP XmNhighlightPixmap <XM_PRIMITIVE_WIDGET_CLASS> -- XmRPrimHighlightPixmap <XM_MANAGER_WIDGET_CLASS> -- XmRManHighlightPixmap :XMN_ARM_PIXMAP XmNarmPixmap XM_PUSH_BUTTON_WIDGET_CLASS -- XmRPrimForegroundPixmap XM_PUSH_BUTTON_GADGET_CLASS -- XmRGadgetPixmap :XMN_SYMBOL_PIXMAP XmNsymbolPixmap XM_MESSAGE_BOX_WIDGET_CLASS -- XmRManForegroundPixmap :XMN_TOP_SHADOW_PIXMAP XmNtopShadowPixmap <XM_PRIMITIVE_WIDGET_CLASS> -- XmRPrimTopShadowPixmap; <XM_MANAGER_WIDGET_CLASS> -- XmRManTopShadowPixmap :XMN_BOTTOM_SHADOW_PIXMAP XmNbottomShadowPixmap <XM_PRIMITIVE_WIDGET_CLASS> -- XmRPrimBottomShadowPixmap; <XM_MANAGER_WIDGET_CLASS> -- XmRManBottomShadowPixmap ______________________________________________________________________________ #ifdef MOTIF_1.0 ** XmRPosition: [Motif 1.0 only] *** Type Information: Resource representation type XmRPosition corresponds to WINTERP-Lisp type FIXNUM. Note that on some architectures, WINTERP will signal an XLISP error if the FIXNUM is too large or too small of an integer. You may also specify a STRING value which will be automatically converted to XmRPosition by Motif's resource converters. *** Resource names and the widget classes they apply to: :XMN_X XmNx <WIDGET_CLASS> <SHELL_WIDGET_CLASS> :XMN_Y XmNy <WIDGET_CLASS> <SHELL_WIDGET_CLASS> :XMN_SASH_INDENT XmNsashIndent XM_PANED_WINDOW_WIDGET_CLASS #endif /* MOTIF_1.0 */ ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRHorizontalPosition: [Motif 1.1 only] *** Type Information: Resource representation type XmRHorizontalPosition corresponds to WINTERP-Lisp type FIXNUM. Note that on some architectures, WINTERP will signal an XLISP error if the FIXNUM is too large or too small of an integer. If you specify a string as the value of an XmRHorizontalPosition, Motif 1.1 will automatically convert the string to a horizontal axis position using Motif's "resolution independence" capabilities. For more information on resolution independence, see the :XMN_UNIT_TYPE (XmNunitType) resource description in the manual pages for XmGadget(3X), XmManager(3X), and XmPrimitive(3X). Also see the :XMN_SHELL_UNIT_TYPE (XmNshellUnitType) resource description in VendorShell(3X). *** Resource names and the widget classes they apply to: :XMN_X XmNx <WIDGET_CLASS> <SHELL_WIDGET_CLASS> :XMN_SASH_INDENT XmNsashIndent XM_PANED_WINDOW_WIDGET_CLASS #endif /* MOTIF_1.1 */ ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRVerticalPosition: [Motif 1.1 only] *** Type Information: Resource representation type XmRVerticalPosition corresponds to WINTERP-Lisp type FIXNUM. Note that on some architectures, WINTERP will signal an XLISP error if the FIXNUM is too large or too small of an integer. If you specify a string as the value of an XmRVerticalPosition, Motif 1.1 will automatically convert the string to a vertical axis position using Motif's "resolution independence" capabilities. For more information on resolution independence, see the :XMN_UNIT_TYPE (XmNunitType) resource description in the manual pages for XmGadget(3X), XmManager(3X), and XmPrimitive(3X). Also see the :XMN_SHELL_UNIT_TYPE (XmNshellUnitType) resource description in VendorShell(3X). *** Resource names and the widget classes they apply to: :XMN_Y XmNy <WIDGET_CLASS> <SHELL_WIDGET_CLASS> #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRProcessingDirection: *** Type Information: Resource representation type XmRProcessingDirection corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :MAX_ON_TOP XmMAX_ON_TOP :MAX_ON_BOTTOM XmMAX_ON_BOTTOM :MAX_ON_LEFT XmMAX_ON_LEFT :MAX_ON_RIGHT XmMAX_ON_RIGHT You may also specify a STRING value which will be automatically converted to XmRProcessingDirection by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. #ifdef MOTIF_1.0 Note -- :GET_VALUES on a horizontally oriented scale or scrollbar widget will return :MAX_ON_TOP or :MAX_ON_BOTTOM instead of :MAX_ON_LEFT and :MAX_ON_RIGHT. This is due to a bug in Motif 1.0. #else The problem above has been fixed in Motif 1.1. #endif /* MOTIF_1.0 */ *** Resource names and the widget classes they apply to: :XMN_PROCESSING_DIRECTION XmNprocessingDirection XM_SCALE_WIDGET_CLASS XM_SCROLL_BAR_WIDGET_CLASS ______________________________________________________________________________ ** XmRResizePolicy: *** Type Information: Resource representation type XmRResizePolicy corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :RESIZE_NONE XmRESIZE_NONE :RESIZE_GROW XmRESIZE_GROW :RESIZE_ANY XmRESIZE_ANY You may also specify a STRING value which will be automatically converted to XmRResizePolicy by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_RESIZE_POLICY XmNresizePolicy XM_BULLETIN_BOARD_WIDGET_CLASS XM_COMMAND_WIDGET_CLASS XM_DRAWING_AREA_WIDGET_CLASS ______________________________________________________________________________ ** XmRRowColumnType: *** Type Information: Resource representation type XmRRowColumnType corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :WORK_AREA XmWORK_AREA :MENU_BAR XmMENU_BAR :MENU_POPUP XmMENU_POPUP :MENU_PULLDOWN XmMENU_PULLDOWN :MENU_OPTION XmMENU_OPTION You may also specify a STRING value which will be automatically converted to XmRRowColumnType by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_ROW_COLUMN_TYPE XmNrowColumnType XM_ROW_COLUMN_WIDGET_CLASS ______________________________________________________________________________ ** XmRScrollBarDisplayPolicy: *** Type Information: Resource representation type XmRScrollBarDisplayPolicy corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :STATIC XmSTATIC :AS_NEEDED XmAS_NEEDED You may also specify a STRING value which will be automatically converted to XmRScrollBarDisplayPolicy by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_SCROLL_BAR_DISPLAY_POLICY XmNscrollBarDisplayPolicy XM_LIST_WIDGET_CLASS XM_SCROLLED_WINDOW_WIDGET_CLASS ______________________________________________________________________________ ** XmRScrollBarPlacement: *** Type Information: Resource representation type XmRScrollBarPlacement corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :TOP_LEFT XmTOP_LEFT :BOTTOM_LEFT XmBOTTOM_LEFT :TOP_RIGHT XmTOP_RIGHT :BOTTOM_RIGHT XmBOTTOM_RIGHT You may also specify a STRING value which will be automatically converted to XmRScrollBarPlacement by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_SCROLL_BAR_PLACEMENT XmNscrollBarPlacement XM_SCROLLED_WINDOW_WIDGET_CLASS ______________________________________________________________________________ ** XmRScrollingPolicy: *** Type Information: Resource representation type XmRScrollingPolicy corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :AUTOMATIC XmAUTOMATIC :APPLICATION_DEFINED XmAPPLICATION_DEFINED You may also specify a STRING value which will be automatically converted to XmRScrollingPolicy by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_SCROLLING_POLICY XmNscrollingPolicy XM_SCROLLED_WINDOW_WIDGET_CLASS ______________________________________________________________________________ ** XmRSelectionArray: *** Type Information: Resource representation type XmRSelectionArray corresponds to an array or list containing the following keyword symbols. The first keyword symbol represents the XmText/XmTextField selection that is done on the first mouse click, the second keyword represents the selection done for two mouse clicks, etc. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :SELECT_POSITION XmSELECT_POSITION :SELECT_WHITESPACE XmSELECT_WHITESPACE :SELECT_WORD XmSELECT_WORD :SELECT_LINE XmSELECT_LINE :SELECT_ALL XmSELECT_ALL #ifdef MOTIF_1.1 :SELECT_PARAGRAPH XmSELECT_PARAGRAPH #endif /* MOTIF_1.1 */ You may also specify a STRING value which will be automatically converted to XmRSelectionPolicy by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_SELECTION_ARRAY XmNselectionArray XM_TEXT_WIDGET_CLASS #ifdef MOTIF_1.1 XM_TEXT_FIELD_WIDGET_CLASS #endif /* MOTIF_1.1 */ Note -- if you set resource :XMN_SELECTION_ARRAY, make sure you also set resource :XMN_SELECTION_ARRAY_COUNT to EXACTLY the number of items in the selection array. ______________________________________________________________________________ ** XmRSelectionPolicy: *** Type Information: Resource representation type XmRSelectionPolicy corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :SINGLE_SELECT XmSINGLE_SELECT :MULTIPLE_SELECT XmMULTIPLE_SELECT :EXTENDED_SELECT XmEXTENDED_SELECT :BROWSE_SELECT XmBROWSE_SELECT You may also specify a STRING value which will be automatically converted to XmRSelectionPolicy by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_SELECTION_POLICY XmNselectionPolicy XM_LIST_WIDGET_CLASS ______________________________________________________________________________ ** XmRSeparatorType: *** Type Information: Resource representation type XmRSeparatorType corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :NO_LINE XmNO_LINE :SINGLE_LINE XmSINGLE_LINE :DOUBLE_LINE XmDOUBLE_LINE :SINGLE_DASHED_LINE XmSINGLE_DASHED_LINE :DOUBLE_DASHED_LINE XmDOUBLE_DASHED_LINE :SHADOW_ETCHED_IN XmSHADOW_ETCHED_IN :SHADOW_ETCHED_OUT XmSHADOW_ETCHED_OUT You may also specify a STRING value which will be automatically converted to XmRSeparatorType by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_SEPARATOR_TYPE XmNseparatorType XM_SEPARATOR_GADGET_CLASS XM_SEPARATOR_WIDGET_CLASS ______________________________________________________________________________ ** XmRShadowType: *** Type Information: Resource representation type XmRShadowType corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :SHADOW_ETCHED_IN XmSHADOW_ETCHED_IN :SHADOW_ETCHED_OUT XmSHADOW_ETCHED_OUT :SHADOW_IN XmSHADOW_IN :SHADOW_OUT XmSHADOW_OUT You may also specify a STRING value which will be automatically converted to XmRShadowType by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_SHADOW_TYPE XmNshadowType XM_BULLETIN_BOARD_WIDGET_CLASS XM_DRAWN_BUTTON_WIDGET_CLASS XM_FRAME_WIDGET_CLASS ______________________________________________________________________________ ** XmRShort: *** Type Information: Resource representation type XmRShort corresponds to WINTERP-Lisp type FIXNUM. Note that on some architectures, WINTERP will signal an XLISP error if the FIXNUM is too large or too small of an integer. You may also specify a STRING value which will be automatically converted to XmRShort by Motif's resource converters. *** Resource names and the widget classes they apply to: :XMN_NUM_COLUMNS XmNnumColumns XM_ROW_COLUMN_WIDGET_CLASS :XMN_DECIMAL_POINTS XmNdecimalPoints XM_SCALE_WIDGET_CLASS :XMN_TEXT_COLUMNS XmNtextColumns XM_SELECTION_BOX_WIDGET_CLASS :XMN_COLUMNS XmNcolumns XM_TEXT_WIDGET_CLASS #ifdef MOTIF_1.1 XM_TEXT_FIELD_WIDGET_CLASS #endif /* MOTIF_1.1 */ :XMN_ROWS XmNrows XM_TEXT_WIDGET_CLASS #ifdef MOTIF_1.0 :XMN_SHADOW_THICKNESS XmNshadowThickness XM_BULLETIN_BOARD_WIDGET_CLASS XM_CASCADE_BUTTON_WIDGET_CLASS XM_CASCADE_BUTTON_GADGET_CLASS XM_DRAWN_BUTTON_WIDGET_CLASS <XM_GADGET_CLASS> XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS <XM_MANAGER_WIDGET_CLASS> <XM_PRIMITIVE_WIDGET_CLASS> XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS XM_SCROLLED_WINDOW_WIDGET_CLASS :XMN_MARGIN_WIDTH XmNmarginWidth XM_BULLETIN_BOARD_WIDGET_CLASS XM_DRAWING_AREA_WIDGET_CLASS XM_FRAME_WIDGET_CLASS XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS XM_PANED_WINDOW_WIDGET_CLASS XM_TEXT_WIDGET_CLASS Note: if :get_values of :XMN_MARGIN_WIDTH on XM_ROW_COLUMN_WIDGET_CLASS retrieves bogus values use resource :XMN_RCMARGIN_WIDTH instead. This is may be a Motif 1.0 bug on some architectures. :XMN_MARGIN_HEIGHT XmNmarginHeight XM_BULLETIN_BOARD_WIDGET_CLASS XM_DRAWING_AREA_WIDGET_CLASS XM_FRAME_WIDGET_CLASS XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS XM_PANED_WINDOW_WIDGET_CLASS XM_TEXT_WIDGET_CLASS Note: if :get_values of :XMN_MARGIN_HEIGHT on XM_ROW_COLUMN_WIDGET_CLASS retrieves bogus values use resource :XMN_RCMARGIN_HEIGHT instead. This may be a Motif 1.0 bug on some architectures. :XMN_HIGHLIGHT_THICKNESS XmNhighlightThickness <XM_GADGET_CLASS> <XM_PRIMITIVE_WIDGET_CLASS> XM_SCALE_WIDGET_CLASS :XMN_MARGIN_LEFT XmNmarginLeft XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS :XMN_MARGIN_RIGHT XmNmarginRight XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS :XMN_MARGIN_TOP XmNmarginTop XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS :XMN_MARGIN_BOTTOM XmNmarginBottom XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS :XMN_LIST_SPACING XmNlistSpacing XM_LIST_WIDGET_CLASS :XMN_LIST_MARGIN_WIDTH XmNlistMarginWidth XM_LIST_WIDGET_CLASS :XMN_LIST_MARGIN_HEIGHT XmNlistMarginHeight XM_LIST_WIDGET_CLASS :XMN_MAIN_WINDOW_MARGIN_WIDTH XmNmainWindowMarginWidth XM_MAIN_WINDOW_WIDGET_CLASS :XMN_MAIN_WINDOW_MARGIN_HEIGHT XmNmainWindowMarginHeight XM_MAIN_WINDOW_WIDGET_CLASS :XMN_SHOW_AS_DEFAULT XmNshowAsDefault XM_PUSH_BUTTON_WIDGET_CLASS XM_PUSH_BUTTON_GADGET_CLASS :XMN_SCROLLED_WINDOW_MARGIN_WIDTH XmNscrolledWindowMarginWidth XM_SCROLLED_WINDOW_WIDGET_CLASS :XMN_SCROLLED_WINDOW_MARGIN_HEIGHT XmNscrolledWindowMarginHeight XM_SCROLLED_WINDOW_WIDGET_CLASS :XMN_MARGIN XmNmargin XM_SEPARATOR_WIDGET_CLASS XM_SEPARATOR_GADGET_CLASS #endif /* MOTIF_1.0 */ ______________________________________________________________________________ ** XmRString: *** Type Information: Resource representation type XmRString corresponds to winter-Lisp type STRING. *** Garbage Collection of strings: XLISP will reclaim storage on any STRING values that are no longer referenced inside WINTERP. *** Resource names and the widget classes they apply to: :XMN_ACCELERATOR XmNaccelerator XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS :XMN_MENU_ACCELERATOR XmNmenuAccelerator XM_ROW_COLUMN_WIDGET_CLASS :XMN_STRING XmNvalue XM_TEXT_WIDGET_CLASS Note -- :XMN_STRING is an alias for resource XmNvalue on the Motif Text Widget. Motif 1.0 & 1.1 has a bug in that it inconsistently declares the value associated with the "message" XmNvalue as 'int' for other widget classes, and as a 'string' for the text widget. Thus, to retrieve or set the string in a text widget, use this resource name, or use text widget methods :GET_STRING and :SET_STRING. :XMN_GEOMETRY XmNgeometry <SHELL_WIDGET_CLASS> :XMN_TITLE XmNtitle <SHELL_WIDGET_CLASS> :XMN_ICON_NAME XmNiconName TOP_LEVEL_SHELL_WIDGET_CLASS TOP_LEVEL_POPUP_SHELL_WIDGET_CLASS :XMN_MWM_MENU XmNmwmMenu <SHELL_WIDGET_CLASS> #ifdef MOTIF_1.1 :XMN_MNEMONIC_CHAR_SET XmNmnemonicCharSet XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS XM_ROW_COLUMN_WIDGET_CLASS Note -- :XMN_MNEMONIC_CHAR_SET is to be set to a CharSet value for Motif. Example values would be "", which is equivalent to the C Motif constant XmSTRING_DEFAULT_CHARSET; another typical value is "ISO8859-1", which is equivalent to the C Motif constants XmSTRING_ISO8859_1, XmSTRING_OS_CHARSET, and XmFALLBACK_CHARSET. For Motif 1.1, potential values for <charset> are: "" (default) "ISO8859-1" "ISO8859-2" "ISO8859-3" "ISO8859-4" "ISO8859-5" "ISO8859-6" "ISO8859-7" "ISO8859-8" "ISO8859-9" "JISX0201.1976-0" "GB2312.1980-0" "GB2312.1980-1" "JISX0208.1983-0" "JISX0208.1983-1" "KSC5601.1987-0" "KSC5601.1987-1" :XMN_MENU_POST XmNmenuPost XM_ROW_COLUMN_WIDGET_CLASS #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRStringDirection: *** Type Information: Resource representation type XmRStringDirection corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :STRING_DIRECTION_L_TO_R XmSTRING_DIRECTION_L_TO_R :STRING_DIRECTION_R_TO_L XmSTRING_DIRECTION_R_TO_L You may also specify a STRING value which will be automatically converted to XmRStringDirection by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_STRING_DIRECTION XmNstringDirection XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS XM_LIST_WIDGET_CLASS #ifdef MOTIF_1.0 XM_BULLETIN_BOARD_WIDGET_CLASS #endif /* MOTIF_1.0 */ #ifdef MOTIF_1.1 <XM_MANAGER_WIDGET_CLASS> #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRStringTable: *** Type Information: One may set an XmRStringTable resource by passing a ARRAY or LIST of STRINGs. *** Resource names and the widget classes they apply to: #ifdef MOTIF_1.1 :XMN_BUTTON_MNEMONIC_CHAR_SETS XmNbuttonMnemonicCharSets <XM_ROW_COLUMN_WIDGET_CLASS created w/ :SIMPLE_*> Note -- this XmCreateSimple*() resource is write-only and can only be set at widget-creation-time. Setting this resource via :SET_VALUES will do nothing, and retrieval using :GET_VALUES will signal an error. :XMN_BUTTON_ACCELERATORS XmNbuttonAccelerators <XM_ROW_COLUMN_WIDGET_CLASS created w/ :SIMPLE_*> Note -- this XmCreateSimple*() resource is write-only and can only be set at widget-creation-time. Setting this resource via :SET_VALUES will do nothing, and retrieval using :GET_VALUES will signal an error. #endif /* MOTIF_1.1 */ :XMN_ARGV XmNargv APPLICATION_SHELL_WIDGET_CLASS Note -- Although resource XmNargv takes values that are arrays of strings, the usual Xtoolkit b.s. strikes again because this resource doesn't work like normal resources with respect to copying values passed during creation or :SET_VALUES. Further Xtoolkit stupidities prevent retrieval of this resource using :GET_VALUES. Therefore Winterp-Resource :XMN_ARGV does not actually exist, instead, use the following methods: (send <Application_Shell_Widget_Instance> :SET_ARGV <args>) (send <Application_Shell_Widget_Instance> :GET_ARGV). ______________________________________________________________________________ #ifdef MOTIF_1.1 ** XmRTextPosition: [MOTIF 1.1 only] *** Type Information: Resource representation type XmRTextPosition corresponds to WINTERP-Lisp type FIXNUM. Only non-negative values are allowed. Negative values will signal an error. *** Resource names and the widget classes they apply to: :XMN_TOP_CHARACTER XmNtopCharacter XM_TEXT_WIDGET_CLASS Note: XmNtopCharacter in Motif 1.1 corresponds to resource XmNtopPosition from Motif 1.0. The name was changed in Motif 1.1. :XMN_CURSOR_POSITION XmNcursorPosition XM_TEXT_WIDGET_CLASS XM_TEXT_FIELD_WIDGET_CLASS #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRTranslationTable: *** Type Information: Resource representation type XmRTranslationTable corresponds to the atomic type XT_TRANSLATIONS as returned by primitive XT_PARSE_TRANSLATION_TABLE. One may set XmRTranslationTable resources by specifying a STRING translation table, just as you would in file $HOME/.Xdefaults. Alternatively, one can use the result of :get_values on another widget's XmRTranslationTable resource or use primitive XT_PARSE_TRANSLATION_TABLE as a XmRTranslationTable value. For more information on the syntax of the string representation of translation tables, see the X11r4 documentation "X Toolkit Intrinsics -- C Language Interface": "Appendix B: Translation Table Syntax" and "Chapter 10: Translation Management". *** Resource names and the widget classes they apply to: :XMN_TEXT_TRANSLATIONS XmNtextTranslations XM_BULLETIN_BOARD_WIDGET_CLASS :XMN_TRANSLATIONS XmNtranslations <WIDGET_CLASS> ______________________________________________________________________________ ** XmRUnitType: *** Type Information: Resource representation type XmRUnitType corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :PIXELS XmPIXELS :100TH_MILLIMETERS Xm100TH_MILLIMETERS :1000TH_INCHES Xm1000TH_INCHES :100TH_POINTS Xm100TH_POINTS :100TH_FONT_UNITS Xm100TH_FONT_UNITS You may also specify a STRING value which will be automatically converted to XmRUnitType by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_UNIT_TYPE XmNunitType <XM_GADGET_CLASS> <XM_MANAGER_WIDGET_CLASS> <XM_PRIMITIVE_WIDGET_CLASS> :XMN_SHELL_UNIT_TYPE XmNshellUnitType <SHELL_WIDGET_CLASS> ______________________________________________________________________________ ** XmRVisualPolicy: *** Type Information: Resource representation type XmRVisualPolicy corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated Motif constants: :VARIABLE XmVARIABLE :CONSTANT XmCONSTANT You may also specify a STRING value which will be automatically converted to XmRVisualPolicy by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_VISUAL_POLICY XmNvisualPolicy XM_SCROLLED_WINDOW_WIDGET_CLASS ______________________________________________________________________________ ** XmRWhichButton: *** Type Information: Resource representation type XmRWhichButton corresponds to an enumerated type. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated X constants: :BUTTON1 Button1 :BUTTON2 Button2 :BUTTON3 Button3 :BUTTON4 Button4 :BUTTON5 Button5 You may also specify a STRING value which will be automatically converted to XmRWhichButton by Motif's resource converters. These values would be the same as one would specify in $HOME/.Xdefaults. *** Resource names and the widget classes they apply to: :XMN_WHICH_BUTTON XmNwhichButton XM_ROW_COLUMN_WIDGET_CLASS ______________________________________________________________________________ ** "XmRWidget", XmRMenuWidget: *** Type Information: Resource representation type "XmRWidget" corresponds to WINTERP-Lisp OBJECT type WIDGETOBJ. Note that Motif 1.0 nor the Xtoolkit define a representation type "XmRWidget" -- this is a fake type used for all resources that expect a value of type 'Widget'. In many cases, Motif 1.0 misdeclares such values as being of representation type XmRWindow. Additionally, the fake representation type "XmRWidget" subsumes the type XmRMenuWidget, which is used for a few Motif resources. This won't matter for automatic string-->XmRWidget conversions because Motif doesn't provide a converters to XmRWidget, XmRMenuWidget, nor XmRWindow. *** Garbage collection of WIDGETOBJs Every WIDGETOBJ that gets created will not be garbage collected until the widget is destroyed. This is needed for proper operation of the get-moused-widget function, and for getting back the correct WIDGETOBJ when a WIDGETOBJ is retrieved from the Motif Toolkit internals. This could be made optional in the future because some memory could be saved, and garbage collection times potentially reduced if only the widgets that are actually being referenced in Lisp code are protected against g.c. When a WIDGETOBJ gets :DESTROY'd, all it's WINTERP-XLISP memory and resources may be garbage collected. This includes any PIXMAPs, CALLBACKOBJs, EVHANDLEROBJs, etc that correspond to the widget. *** Resource names and the widget classes they apply to: #ifdef MOTIF_1.1 :XMN_TRANSIENT_FOR XmNtransientFor TRANSIENT_POPUP_SHELL_WIDGET_CLASS TRANSIENT_SHELL_WIDGET_CLASS #endif /* MOTIF_1.1 */ :XMN_SUB_MENU_ID XmNsubMenuId XM_CASCADE_BUTTON_WIDGET_CLASS XM_CASCADE_BUTTON_GADGET_CLASS XM_ROW_COLUMN_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation type XmRMenuWidget. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. :XMN_MENU_HELP_WIDGET XmNmenuHelpWidget XM_ROW_COLUMN_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation type XmRMenuWidget. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. Note -- resource name :XMN_MENU_HELP_WIDGET is defined only for a row column widget created with the :menu_bar or :simple_menu_bar option. Using this resource with other variants of the row column widget is underfined and unguaranteed. :XMN_MENU_HISTORY XmNmenuHistory XM_ROW_COLUMN_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation type XmRMenuWidget. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. Note -- resource name :XMN_MENU_HISTORY is defined only for row column widgets created with the :popup_menu, :simple_popup_menu, :pulldown_menu, or :simple_pulldown_menu options. Using this resource with other variants of the row column widget is undefined and unguaranteed. :XMN_DEFAULT_BUTTON XmNdefaultButton XM_BULLETIN_BOARD_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. :XMN_CANCEL_BUTTON XmNcancelButton XM_BULLETIN_BOARD_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. :XMN_TOP_WIDGET XmNtopWidget XM_FORM_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. :XMN_BOTTOM_WIDGET XmNbottomWidget XM_FORM_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. :XMN_LEFT_WIDGET XmNleftWidget XM_FORM_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. :XMN_RIGHT_WIDGET XmNrightWidget XM_FORM_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. :XMN_HORIZONTAL_SCROLL_BAR XmNhorizontalScrollBar XM_LIST_WIDGET_CLASS XM_SCROLLED_WINDOW_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. :XMN_VERTICAL_SCROLL_BAR XmNverticalScrollBar XM_LIST_WIDGET_CLASS XM_SCROLLED_WINDOW_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. :XMN_COMMAND_WINDOW XmNcommandWindow XM_MAIN_WINDOW_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. :XMN_MENU_BAR XmNmenuBar XM_MAIN_WINDOW_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. #ifdef MOTIF_1.1 :XMN_MESSAGE_WINDOW XmNmessageWindow XM_MAIN_WINDOW_WIDGET_CLASS Note -- Motif (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. #endif /* MOTIF_1.1 */ :XMN_WORK_WINDOW XmNworkWindow XM_SCROLLED_WINDOW_WIDGET_CLASS Note -- Motif 1.0 (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. :XMN_CLIP_WINDOW XmNclipWindow XM_SCROLLED_WINDOW_WIDGET_CLASS Note -- Motif 1.0 (mis)declares this resource as representation XmRWindow. I'm throwing it in with "XmRWidget" because these resources are WIDGETOBJs. ______________________________________________________________________________ ** "XmRWidgetClass": *** Type Information: Resource representation type XmRWidgetClass corresponds to WINTERP-Lisp OBJECT. In particular, this OBJECT must be a class object that is a subclass of WIDGET_CLASS. Note that neither Motif nor the Xtoolkit define a representation type "XmRWidgetClass" -- this is a fake type used for all resources that expect a value of type 'WidgetClass'. *** Resource names and the widget classes they apply to: :XMN_ENTRY_CLASS XmNentryClass XM_ROW_COLUMN_WIDGET_CLASS Note -- Motif 1.0 & 1.1 misdeclares resource XmNentryClass as representation type XmRInt. The value for this resource is actually a 'WidgetClass' pointer. ______________________________________________________________________________ ** XmRWindow: *** Type Information: Resource representation type XmRWindow corresponds to WINTERP-Lisp atomic type WINDOW. This type is returned by some callbacks, as well as by WIDGET_CLASS method :WINDOW. *** Resource names and the widget classes they apply to: :XMN_ICON_WINDOW XmNiconWindow <SHELL_WIDGET_CLASS> :XMN_WINDOW_GROUP XmNwindowGroup <SHELL_WIDGET_CLASS> ______________________________________________________________________________ #ifdef MOTIF_1.1 ** "XmRWindowGravity": [MOTIF 1.1 only] *** Type Information: Resource representation type "XmRWindowGravity" corresponds to an enumerated type. Note that neither Motif nor the Xtoolkit define a representation type "XmRWindowGravity". Resources of this type are declared as XmRInt, even though they work like enumerated types. The following keyword symbols represent the valid WINTERP-Lisp values for this type and their associated <X11/X.h> constants: :FORGET_GRAVITY ForgetGravity :NORTH_WEST_GRAVITY NorthWestGravity :NORTH_GRAVITY NorthGravity :NORTH_EAST_GRAVITY NorthEastGravity :WEST_GRAVITY WestGravity :CENTER_GRAVITY CenterGravity :EAST_GRAVITY EastGravity :SOUTH_WEST_GRAVITY SouthWestGravity :SOUTH_GRAVITY SouthGravity :SOUTH_EAST_GRAVITY SouthEastGravity :STATIC_GRAVITY StaticGravity *** Resource names and the widget classes they apply to: :XMN_WIN_GRAVITY XmNwinGravity <SHELL_WIDGET_CLASS> <POPUP_SHELL_WIDGET_CLASS> #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRXmString: *** Type Information: Resource representation type XmRXmString corresponds to the atomic type XM_STRING as returned by primitives XM_STRING_CREATE_L_TO_R and XM_STRING_CREATE. Any XM_STRING value needed by a Motif function, method or resource may be substituted for a STRING. WINTERP will automatically call XmStringCreateLtoR() to convert STRING values to XM_STRING values. Note that Motif XmStrings are problematic in that the XmString resources you set via :SET_VALUES (or at widget creation time) are guaranteed not to be EQ, EQL or EQUAL to the ones you retrieve via :GET_VALUES or via a widget method. In order to check for XmString equality, you have to call XmStringCompare(), via primitive XM_STRING_COMPARE. XmStringCompare() is quite inefficient, so be careful about how you use it. For example, you should ignore the way the Motif documentation shows you to use the XmList widget. Intead, use the technique demonstrated above in the section "Example of using OOP features of XLISP with Motif widgets". In order to retrieve a STRING value from an XM_STRING value, use primitive XM_STRING_GET_L_TO_R. *** Garbage collection of XM_STRINGs: Storage associated with XM_STRINGs is freed via XmStringFree() when a XM_STRING node gets garbage collected. Garbage collection of XM_STRINGs occurs when they are no longer accessible by a Lisp variable. *** Resource names and the widget classes they apply to: :XMN_DIALOG_TITLE XmNdialogTitle XM_BULLETIN_BOARD_WIDGET_CLASS :XMN_PROMPT_STRING XmNpromptString XM_COMMAND_WIDGET_CLASS :XMN_COMMAND XmNcommand XM_COMMAND_WIDGET_CLASS :XMN_TEXT_STRING XmNtextString XM_SELECTION_BOX_WIDGET_CLASS :XMN_LABEL_STRING XmNlabelString XM_DRAWN_BUTTON_WIDGET_CLASS XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS XM_ROW_COLUMN_WIDGET_CLASS :XMN_LIST_LABEL_STRING XmNlistLabelString XM_FILE_SELECTION_BOX_WIDGET_CLASS XM_SELECTION_BOX_WIDGET_CLASS :XMN_APPLY_LABEL_STRING XmNapplyLabelString XM_FILE_SELECTION_BOX_WIDGET_CLASS XM_SELECTION_BOX_WIDGET_CLASS :XMN_DIR_SPEC XmNdirSpec XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_FILTER_LABEL_STRING XmNfilterLabelString XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_DIR_MASK XmNdirMask XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_ACCELERATOR_TEXT XmNacceleratorText XM_LABEL_WIDGET_CLASS XM_LABEL_GADGET_CLASS :XMN_MESSAGE_STRING XmNmessageString XM_MESSAGE_BOX_WIDGET_CLASS :XMN_OK_LABEL_STRING XmNokLabelString XM_MESSAGE_BOX_WIDGET_CLASS XM_SELECTION_BOX_WIDGET_CLASS :XMN_CANCEL_LABEL_STRING XmNcancelLabelString XM_MESSAGE_BOX_WIDGET_CLASS XM_SELECTION_BOX_WIDGET_CLASS :XMN_HELP_LABEL_STRING XmNhelpLabelString XM_MESSAGE_BOX_WIDGET_CLASS XM_SELECTION_BOX_WIDGET_CLASS :XMN_TITLE_STRING XmNtitleString XM_SCALE_WIDGET_CLASS :XMN_SELECTION_LABEL_STRING XmNselectionLabelString XM_SELECTION_BOX_WIDGET_CLASS #ifdef MOTIF_1.1 :XMN_DIRECTORY XmNdirectory XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_PATTERN XmNpattern XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_DIR_LIST_LABEL_STRING XmNdirListLabelString XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_NO_MATCH_STRING XmNnoMatchString XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_FILE_LIST_LABEL_STRING XmNfileListLabelString XM_FILE_SELECTION_BOX_WIDGET_CLASS :XMN_OPTION_LABEL XmNoptionLabel <XM_ROW_COLUMN_WIDGET_CLASS created w/ :SIMPLE_OPTION_MENU> #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** XmRXmStringTable: *** Type Information: One may set an XmRXmStringTable resource by passing a ARRAY or LIST value containing either STRING or XM_STRING nodes. Any STRING values are automatically converted to XmStrings via XmStringCreateLtoR(). Limitations in the design of Motif/Xtk prevent WINTERP from being able to retrieve XmRXmStringTable resources using WIDGET_CLASS method :GET_VALUES. Accessor methods are provided to allow retrieval of these resources.... *** Garbage Collection of XmRXmStringTable: A Motif XmStringTable is represented as an array or list of XmStrings. The XmStrings in these sequences will get garbage collected if the vector or array holding them gets collected. *** Resource names and the widget classes they apply to: :XMN_HISTORY_ITEMS XmNhistoryItems XM_COMMAND_WIDGET_CLASS [note: :GET_VALUES can't retrieve this resource, use method (send <commandwidget> :GET_HISTORY_ITEMS)] :XMN_ITEMS XmNitems XM_LIST_WIDGET_CLASS [note: :GET_VALUES can't retrieve this resource, use method (send <listwidget> :GET_ITEMS)] :XMN_SELECTED_ITEMS XmNselectedItems XM_LIST_WIDGET_CLASS [note: :GET_VALUES can't retrieve this resource, use method (send <listwidget> :GET_SELECTED_ITEMS)] :XMN_LIST_ITEMS XmNlistItems XM_SELECTION_BOX_WIDGET_CLASS [note: :GET_VALUES can't retrieve this resource, use method (send <selectionbox> :GET_LIST_ITEMS)] #ifdef MOTIF_1.1 :XMN_DIR_LIST_ITEMS XmNdirListItems XM_FILE_SELECTION_BOX_WIDGET_CLASS [note: :GET_VALUES can't retrieve this resource, use method (send <fileselboxwidget> :GET_DIR_LIST_ITEMS)] :XMN_FILE_LIST_ITEMS XmNfileListItems XM_FILE_SELECTION_BOX_WIDGET_CLASS [note: :GET_VALUES can't retrieve this resource, use method (send <fileselboxwidget> :GET_FILE_LIST_ITEMS)] :XMN_BUTTONS XmNbuttons <XM_ROW_COLUMN_WIDGET_CLASS created w/ :SIMPLE_*> [note: this resource can be set only at widget-creation time setting via :SET_VALUES will do nothing, and retrieval via :GET_VALUES will signal an error.] :XMN_BUTTON_ACCELERATOR_TEXT XmNbuttonAcceleratorText <XM_ROW_COLUMN_WIDGET_CLASS created w/ :SIMPLE_*> [note: this resource can be set only at widget-creation time setting via :SET_VALUES will do nothing, and retrieval via :GET_VALUES will signal an error.] #endif /* MOTIF_1.1 */ ______________________________________________________________________________ ** Missing Resources in WINTERP: The current version of WINTERP does not allow access to the following resources: XmNsimpleCallback: this is a special inconsistent way of setting callbacks on <XM_ROW_COLUMN_WIDGET_CLASS created w/ :SIMPLE_*>. I suggest using XM_ROW_COLUMN_WIDGET_CLASS's XmNentryCallback instead. See "Note on XmCreateSimple*() routines" above for details. Also, see ./../examples/fake-app.lsp and ./../examples/RowColumn.lsp. XmNchildren/XmNnumChildren: this read-only resource may not be retrieved via WINTERP's :GET_VALUES in a straightforward fashion. Instead, use method (send <composite_widget> :GET_CHILDREN) XmNargv/XmNargc: due to inconsistent behavior of the XmNargv resource you must set and retrieve this resource via the following methods on APPLICATION_SHELL_WIDGET_CLASS: (send <application-shell-widget> :SET_ARGV) (send <application-shell-widget> :GET_ARGV) XmNpostFromCount/XmNpostFromList: these seem to be internal, undocumented resources on XmRowColumn, therefore I'm not going to interface these. If you figure out what these are used for, and need to use them, add a method on XM_ROW_COLUMN_WIDGET_CLASS that is similar to method ./../src-server/wc_WIDGET.c:Widget_Class_Method_GET_CHILDREN(). XmNcolormap: I haven't interfaced this Core/Shell resource because WINTERP does not provide a type COLORMAP yet. If I ever need to fiddle with colormaps directly, this can be added trivially. XmNatom: I haven't interfaced this Xm/Protocols.c resource because it seems to be an undocumented, internal resource used by the protocol manager. XmNtitleEncoding: / XmNiconNameEncoding: I haven't interfaced these shell widget resources because I haven't provided a type ATOM yet. I'll probably add these when I add interfaces to the protocol manager functionality. XmNextensionType: I haven't interfaced this resource because it seems to be an undocumented, internal resource used by Motif. XmNoutputCreate/XmNinputCreate/XmNinsertPosition/XmNcreatePopupChildProc: These resources take a C function-pointer. The kinds of things done by these procedures are probably too low-level to interface to the WINTERP. If you need access to these in WINTERP the simplest thing to do is create a trivial subclass (essentially a C wrapper) of the desired widget-class such that this resource gets set to the desired creation/insert/popup procedure that is implemented in C. XmNuserData: this resource is used internally by WINTERP. If you need to attach your own data to widgets, you may do it by declaring a subclass of the desired widget-class containing instance variables and methods to access the instance variables. XmNsource: This XmText resource takes a C function pointer. The kinds of things done by these procedures are probably too low-level to interface to the WINTERP. If you need access to these in WINTERP the simplest thing to do is create a trivial subclass (essentially a C wrapper) of the XmText such that this resource gets set to the desired C-implemented procedure. XmNqualifySearchDataProc/XmNdirSearchProc/XmNfileSearchProc: These XmFileSelectionBox resources take a C function pointer. The kinds of things done by these procedures are probably too low-level to interface to the WINTERP. If you need access to these in WINTERP the simplest thing to do is create a trivial subclass (essentially a C wrapper) of the XmFileSelectionBox class such that these resources get set to the desired C-implemented procedure. XmNscreen: this Core resource hasn't been interfaced because WINTERP does not yet support multiple screens and does not have a type SCREEN. At some point, it may get updated to support multiple screens, at which point I'll interface this resource. XmNvisual: this Shell resource hasn't been interfaced yet because WINTERP does not support type VISUAL yet, and I haven't needed to use VISUAL in my applications. ============================================================================= * Additional X, Xtoolkit, and Winterp Functionality ** WIDGETOBJP -- primitive to check if lisp value is a widget/gadget. (WIDGETOBJP <expr>) --> returns T if argument is a WIDGETOBJ, else NIL. WIDGETOBJP is a type predicate testing to see if a value is a widget or gadget object. ** :EXISTS_P -- WIDGET_CLASS method to test if widget exists (send <widget> :EXISTS_P) --> returns T if the widget exists (and hasn't been destroyed); returns NIL if the widget has been destroyed or if the widget has never been initialized. Use this method for the following problem: A WIDGETOBJ value may be stored as the value of a symbol, or stored in a functional closure; the lifetime of the widget associated with the WIDGETOBJ is not necessarily the same. This method can test to see if the widget associated with the WIDGETOBJ has been destroyed by the user through some previous operation. Using this method can allow programmers to prevent sending messages to widgets that have been destroyed; normally, sending a message to a destroyed widget would signal an error. ** GET_MOUSED_WIDGET -- primitive for visually interacting with widgets. (GET_MOUSED_WIDGET) --> returns the WIDGETOBJ designated by the user. Evaluating GET_MOUSED_WIDGET will change the cursor to a crossbar, indicating that the user is to 'click' the mouse on a widget managed by WINTERP. GET_MOUSED_WIDGET will then return the WIDGETOBJ corresponding to the selected widget. You can use this primitive to visually alter widgets displayed by WINTERP, for example, evaluating the following form will invert the colors on any widget you click (note -- you can't change the colors on a gadget): (let ((widget (get_moused_widget)) foreground background ) (send widget :get_values :XMN_FOREGROUND 'foreground :XMN_BACKGROUND 'background ) (send widget :set_values :XMN_FOREGROUND background :XMN_BACKGROUND foreground )) You may use this primitive for sending arbitrary messages to arbitrary widgets "visually". This primitive can be used to implement "builder-like" and "hypercard-like" features with WINTERP. For additional examples using this primitive, see ./../examples/interact.lsp Note: GET_MOUSED_WIDGET will work on any kind of widget, not only widgets created at the Lisp level in WINTERP. This means that you can use it to modify widgets inside a composite widget (e.g., the scrollbar in a scrolled text or list widget). Furthermore, if you take an existing C-implemented Motif application and link it in with WINTERP such that your application uses WINTERP's event handling loop in main(), then you can use GET_MOUSED_WIDGET to modify the widgets created in your own C-implemented application code! KNOWN BUG -- you cannot use get_moused_widget primitive on widgets within a menu system. Even if you manage to post a menu that stays posted and then call this function, the "grab" from the menu prevents this primitive from working... Note: if you are using Motif 1.1 and want GET_MOUSED_WIDGET's functionality with the additional ability to control the mouse sprite, see also XM_TRACKING_LOCATE. ** X_ALLOC_COLOR == XParseColor() + XAllocColor(): (X_ALLOC_COLOR <color>) --> returns a PIXEL atom corresponding to a read-only color cell in the installed colormap. <color> is a string, either a colorname from /usr/lib/X11/rgb.txt or a hexadecimal color specification of format "#RRGGBB". ** X_STORE_COLOR == XParseColor() + XStoreColor(): (X_STORE_COLOR <pixel> <color>) --> returns a PIXEL atom. X_STORE_COLOR stores an RGB/Color value into a single read/write colormap cell represented by type-PIXEL atom <pixel>. <color> is a string, either a colorname from /usr/lib/X11/rgb.txt or a hexadecimal color specification of format "#RRGGBB". Note that read/write colormap cells can be created via primitive X_ALLOC_N_COLOR_CELLS_NO_PLANES, and these are useful for generating the appearance of having colors shared by multiple widgets on the screen. For example usage, see ./../examples/colorsetr.lsp . ** X_ALLOC_N_COLOR_CELLS_NO_PLANES == XAllocColorCells(d,c,FALSE,NULL,0,...): (X_ALLOC_N_COLOR_CELLS_NO_PLANES <num-cells>) --> returns an array of <pixel>, each <pixel> being a type-PIXEL atom representing a single read/write color cell in the installed colormap. <num-cells>, a FIXNUM > 0, indicates the number of read/write color cells to allocate. For details, see see Oliver Jones' "Introduction to the X Window System", p. 278. For example usage, see ./../examples/colorsetr.lsp . ** XT_ADD_TIMEOUT / XT_REMOVE_TIMEOUT == XtAppAddTimeout() / XtRemoveTimeout() (XT_ADD_TIMEOUT <interval> <code>) --> returns a <timeout_obj> <interval> is a FIXNUM, the number of milliseconds before the timeout fires. <code> is a list of Lisp expressions that are evaluated when the timeout occurs. During the timeout, the lexical environment that existed for the call to XT_ADD_TIMEOUT will be used for value and functional bindings. Additionally, the symbol TIMEOUT_OBJ is bound to the timeout object that caused the timeout. A variant of the above form allows efficient scheduling of recurrent timeouts when called from within <code> (XT_ADD_TIMEOUT <interval> TIMEOUT_OBJ) Instead of creating a new closure around the same <code> each time a recurrent timeout is rescheduled, this second form for XT_ADD_TIMEOUT allows you to take the TIMEOUT_OBJ from a previously expired timeout and reschedule a new timeout using the closure setup by the initial call to (XT_ADD_TIMEOUT <interval> <code>). During the execution of <code>, the symbol TIMEOUT_OBJ is bound to <timeout-obj> so that you don't need to keep around a global variable for each recurrent timeout. The timeout scheduled by XT_ADD_TIMEOUT may be removed by passing <timeout_obj> into the primitive XT_REMOVE_TIMEOUT: (XT_REMOVE_TIMEOUT <timeout_obj>) <timeout_obj> is the value returned by XT_ADD_TIMEOUT. To test whether the timeout associated with a <timeout_obj> has expired, use: (TIMEOUT_ACTIVE_P <timeout_obj>) --> returns T if <timeout_obj> is still scheduled; returns NIL if <timeout_obj> has expired or if the timeout was inactivated by XT_REMOVE_TIMEOUT. ** Translations, Accelerators, and Actions. *** Action Procedure Lisp() -- call the XLISP evaluator from a translation table. WINTERP has a built-in ActionProc named "Lisp" that allows you to call arbitrary Lisp functions from a translation or accelerator table. The arguments passed on to ActionProc "Lisp" become the elements in the Lisp form passed on to the evaluator when the action is fired. For example, a translation/accelerator table containing an entry "<EnterWindow>: Lisp(Lisp-function arg1 arg2 arg3)" will end up evaluating the Lisp form '(Lisp-function arg1 arg2 arg3)' whenever an EnterWindow event is processed. In the lexical scope of the action invocation, ACTION_WIDGET gets bound to the widget causing the action, and ACTION_XEVENT gets bound to the event. See ./../examples/trans.lsp for examples. KNOWN-BUG: I haven't found a way of escaping characters passed on to the translation/action table parsers to allow Lisp strings or lips lists to be passed on to the Lisp evaluator that is called by this function. Using the evaluator through an action proc is still useful, just don't try to pass in very complex Lisp forms. *** XT_PARSE_TRANSLATION_TABLE == XtParseTranslationTable(): (XT_PARSE_TRANSLATION_TABLE <string>) --> returns a XT_TRANSLATIONS node This primitive compiles <string> into a translation table and returns the compiled table. For more information on the syntax of the string representation of translation tables, see the X11r4 documentation "X Toolkit Intrinsics -- C Language Interface": "Appendix B: Translation Table Syntax" and "Chapter 10: Translation Management". NOTE: the memory allocated by XtParseTranslationTable() isn't freed anywhere yet -- I can't find any documentation that says you're supposed to free this. For now this may be a memory leak. *** XT_PARSE_ACCELERATOR_TABLE == XtParseAcceleratorTable(): (XT_PARSE_ACCELERATOR_TABLE <string>) --> returns a XT_ACCELERATORS node This primitive compiles <string> into an accelerator table and returns the compiled table. For more information on the syntax of the string representation of accelerator tables, see the X11r4 documentation "X Toolkit Intrinsics -- C Language Interface": "Appendix B: Translation Table Syntax" and "Chapter 10: Translation Management". NOTE: the memory allocated by XtParseAcceleratorTable() isn't freed anywhere yet -- I can't find any documentation that says you're supposed to free this. For now this may be a memory leak. ** XM_GET_PIXMAP == XmGetPixmap(): (XM_GET_PIXMAP <image-name> <foreground> <background>) --> returns a PIXMAP node. <image-name> is a string representing a XImage that has been cached via XM_INSTALL_IMAGE. If such an XImage isn't found, then <image-name> is treated as the filename for a X10 or X11 bitmap file. You need to give a full pathname to the bitmap file, or alternately, you may set the environment variable XBMLANGPATH to the directories to be searched for bitmap files. XBMLANGPATH defaults to /usr/lib/X11/%L/bitmaps/%N/%B:/usr/lib/X11/%L/bitmaps/%B:/usr/lib/X11/bitmaps/%B:/usr/include/X11/bitmaps/%B In additions to images you have installed, Motif features 10 preinstalled images: "background", "25_foreground", "50_foreground", "75_foreground", "vertical", "horizontal", "slant_right", "slant_left", "menu_cascade", "menu_checkmark". <foreground> and <background> may be strings representing color names, or values of type PIXEL. (generated by X_ALLOC_COLOR, or via widget-method :get_values on :XMN_FOREGROUND or :XMN_BACKGROUND resources). This function returns a value of type PIXMAP, which is suitable for passing on to any Pixmap-valued widget resource so as to display an image inside a widget. Note that there is no interface to XmDestroyPixmap()-- unreferenced pixmaps are automatically destroyed by WINTERP during garbage collection. ** XM_INSTALL_IMAGE == XmInstallImage(): (XM_INSTALL_IMAGE <ximage> <image_name>) --> returns T if success, NIL if a NULL <ximage>, or duplicate <image_name> is given. This primitive installs an XIMAGE node for use by Motif's Image and Pixmap cacheing routines. <ximage> is an XIMAGE node as returned by XM_GET_XIMAGE_FROM_FILE; <image_name> is a STRING, the name under which the <ximage> is cached. ** XM_UNINSTALL_IMAGE == XmUninstallImage(): (XM_UNINSTALL_IMAGE <ximage>) --> returns T if success, NIL if a NULL <ximage>, or <ximage> cannot be found in the image cache. This primitive removes an XIMAGE from Motif's Image cache, freeing up the storage associated with the XImage. <ximage> is an XIMAGE node as returned by XM_GET_XIMAGE_FROM_FILE ** XM_GET_XIMAGE_FROM_FILE == _XmGetImageFromFile(): (XM_GET_XIMAGE_FROM_FILE <filepath>) --> returns an XIMAGE node if an XImage was successfully retrieved from the given bitmap file; NIL if This primitive reads an X10 or X11 bitmap file and returns an XImage structure associated with that file. <filepath> is a STRING, the full path name to the file containing the XImage data. #ifdef MOTIF_1.1 ** XM_GET_COLORS == XmGetColors() [Motif 1.1 only]: (XM_GET_COLORS <background-pixel>) --> returns an array of 5 PIXEL values #(<background> <foreground> <top_shadow> <bot_shadow> <select>) Given PIXEL-type argument <background-pixel> representing the background color of a widget, XM_GET_COLORS will calculate and return PIXEL type values for foreground, select, and shadow colors. For an example of XM_GET_COLORS usage, see ./../examples/colorsetr.lsp . Note that this routine will change at some future date to take <screen> and <colormap> arguments that are used by XmGetColors(). Currently, XM_GET_COLORS uses the default screen and colormap of the WINTERP application's *TOPLEVEL_WIDGET* #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 ** XM_SET_FONT_UNITS == XmSetFontUnits() [Motif 1.1 only]: (XM_SET_FONT_UNITS <horiz-val> <vert-val>) --> Returns NIL. XM_SET_FONT_UNITS allows applications to initialize the font unit values to nonnegative FIXNUM values <horiz-val> and <vert-val>. Applications may want to specify resolution-independent data based on a global font size. This function must be called before any widgets with resolution-independent data are created. See the documentation on resource :XMN_UNIT_TYPE above, as well as the manual pages for XmGadget, XmManager, and XmPrimitive for more information on resolution independence. Note: when WINTERP allows for multiple displays, this function will end up changing argument sequences to accomodate a <display> arg. #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 ** XM_TRACKING_LOCATE == XmTrackingLocate() [Motif 1.1 only]: (XM_TRACKING_LOCATE <widget> <fontcursor-FIXNUM> [<confine-to-p>]) --> Returns a WIDGETOBJ that was selected by the user. Returns NIL if the window of the buttonpress is not a widget. "XmTrackingLocate provides a modal interface for selection of a component. It is intended to support context help. The function grabs the pointer and returns the widget in which a button press occurs." (taken from XmTrackingLocate.3X man-page). <widget> is the widget "to use as the basis of the modal interaction" <fontcursor-FIXNUM> specifies the shape of the cursor for this interaction. the value of this FIXNUM specifies a font whose name/value is defined in /usr/include/X11/cursorfont.h. If the last arg supplied, <confine-to-p>, is non-NIL, then the interaction will be confined to <widget>. If this arg is not supplied, <confine-to-p> is treated as NIL. Note: See also WINTERP's GET_MOUSED_WIDGET primitive, which offers similar functionality to XM_TRACKING_LOCATE but predates it (XM_TRACKING_LOCATE is new to Motif 1.1). #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 ** XM_CONVERT_UNITS == XmConvertUnits() [Motif 1.1 only]: (XM_CONVERT_UNITS <widget> <orientation> <from_unit_type> <from_value> <to_unit_type>) --> Returns the converted value, a FIXNUM. "XmConvertUnits - a function that converts a value in one unit type to another unit type." (quoted from XmConvertUnits.3X manual page). <widget> is a WIDGETOBJ -- "Specifies the widget for which the data is to be converted." <orientation> is a keyword symbol, either :HORIZONTAL or :VERTICAL "Specifies whether the converter uses the horizontal or vertical screen resolution when performing the conversions." <from_unit_type> and <to_unit_type> are keyword symbols, either :PIXELS, :100TH_MILLIMETERS, :1000TH_INCHES, :100TH_POINTS, :100TH_FONT_UNITS. <from_value> is a FIXNUM. Note that Motif resolution independence functions XmCvtFromHorizontalPixels(), XmCvtFromVerticalPixels(), XmCvtToHorizontalPixels(), XmCvtToVerticalPixels() have not been interfaced since their functionality can be achieved through XmConvertUnits(). #endif /* MOTIF_1.1 */ ** XM_SET_MENU_CURSOR == XmSetMenuCursor(): (XM_SET_MENU_CURSOR <fontcursor>) --> Returns NIL. "XmSetMenuCursor programmatically modifies the menu cursor for a client; after the cursor has been created by the client, this function registers the cursor with the menu system. After calling this function, the specified cursor is displayed whenever this client displays a Motif menu on the indicated display. The client can then specify different cursors on different displays." (from XmSetMenuCursor.3X manual page). <fontcursor>> specifies the shape of the cursor for this interaction. The value of this FIXNUM specifies a font whose name/value is defined in /usr/include/X11/cursorfont.h. Note: when WINTERP allows for multiple displays, this function will end up changing arg sequences to accomodate a <display> arg. #ifdef MOTIF_1.1 ** XT_RESOLVE_PATHNAME == XtResolvePathname() [Motif 1.1 only]: (XT_RESOLVE_PATHNAME <type> <filename> <suffix> <path>) --> returns a STRING representing the pathname of an existing file created from the parameters <type> <filename> <suffix> and <path>. Returns NIL if no such file exists, the file isn't readable, or the specification is a directory. <path> is a string of paths separated by colons (':'), in which the following substitutions are done: %N -- gets substituted by the parameter <filename>, a name without the extension. %T -- gets substituted by the parameter <type>, a directory name. %S -- gets substituted by the parameter <suffix>. X11r4 Language-dependent substitutions for %L, %l %t, %c may occur as well. See the documentation for XtResolvePathname() for further details. <type> is a STRING, or NIL. This substitutes for occurrences of %T in <path>. <filename> is a STRING. If this parameter is NIL, then note that XtResolvePathname() will substitute the application class name. <suffix> is a STRING, or NIL. This substitutes for occurrences of %S in <path>. For a useful example using XT_RESOLVE_PATHNAME, see Winterp-Lisp file ./../examples/prov-req.lsp . #endif /* MOTIF_1.1 */ ** XT_MANAGE_CHILDREN == XtManageChildren(): (XT_MANAGE_CHILDREN <widgets...>) --> returns T. Given <widgets...>, an ARRAY or list of WIDGETOBJs, all of which must be children of the same parent, this primitive will add those widgets to their parent-widget's managed list, which means they will become visible (if mapped) and will take up space within the managing widget. If the shell widget ancestor of <widgets...> has been :REALIZE'd, calling XT_MANAGE_CHILDREN on a sequence of child widgets is more efficient than specifying the :MANAGED option to each child-widget creation form, or sending the :MANAGE message to each child-widget created. Note that the efficiency argument above is moot if the shell widget ancestor of <widgets...> has not been :REALIZE'd. An error will be signaled if the widgets passed to this routine do not all have the same parent. ** XT_UNMANAGE_CHILDREN == XtUnmanageChildren(): (XT_UNMANAGE_CHILDREN <widgets...>) --> returns T. Given <widgets...>, an ARRAY or LIST of WIDGETOBJs, all of which must be children of the same parent, this primitive will remove those widgets from their parent-widget's managed list, which means they will no longer be visible or take up space. Calling XT_UNMANAGE_CHILDREN on a sequence of child widgets is more efficient than sending the :UNMANAGE message to each child-widget. An error will be signaled if the widgets passed to this routine do not all have the same parent. ** GET_MOUSE_LOCATION == XQueryPointer(): (GET_MOUSE_LOCATION) --> returns dotted pair (root-x . root-y) representing the x,y location of the mouse sprite with respect to the root window. To access root-x, use 'car' and to access root-y, use 'cdr'. ** Primitives for manipulating XM_STRINGs: Because Motif's XmStrings are such a complete pain to deal with, I've tried to make it so you can pretend XmStrings don't exist at all by providing automatic string-->XmString conversions for setting resources and for various widget methods. Alas, there are cases where you need to retrieve STRING values from an XM_STRING, create special XM_STRINGs, convert compound text to XM_STRINGs (or vice versa), or need to compare two XM_STRINGS. For such cases, I've interfaced most of Motif's XmString functionality... #ifdef MOTIF_1.1 *** XM_CVT_CT_TO_XM_STRING == XmCvtCTToXmString() [Motif 1.1 only]: (XM_CVT_CT_TO_XM_STRING <compound-text>) --> returns an XM_STRING representing <compound-text>. <compound-text> is an XLISP STRING type but it is encoded using compound text format, which is described in the X Consortium Standard "Compound Text Encoding". #endif /* MOTIF_1.1 */ #ifdef MOTIF_1.1 *** XM_CVT_XM_STRING_TO_CT == XmCvtXmStringToCT() [Motif 1.1 only]: (XM_CVT_XM_STRING_TO_CT <xmstring>) --> returns a STRING. This function converts XM_STRING type argument <xmstring> to a STRING encoded in compound text format. Compound text format is described in the X Consortium Standard "Compound Text Encoding". #endif /* MOTIF_1.1 */ *** XM_STRING_BYTE_COMPARE == XmStringByteCompare(): (XM_STRING_BYTE_COMPARE <xmstring_a> <xmxtring_b>) --> returns T if the XM_STRING args are byte-for-byte equal, else NIL. A Note from XmStringByteCompare.3X manual page: "In general, if two compound strings are created with the same (char *) string using XmStringCreateSimple in the same language environment, the compound strings compare as equal. If two compound strings are created with the same (char *) string and the same character set other than XmSTRING_DEFAULT_CHARSET using XmStringCreate, the strings compare as equal. The result of comparing a compound string created with XmStringCreate against a compound string created with XmStringCreateSimple is undefined. In some cases, once a compound string is put into a widget, that string is converted into an internal form to allow faster processing. Part of the conversion process strips out unnecessary or redundant information. If an application then does an XtGetValues to retrieve a compound string from a widget (specifically, Label and all of its subclasses), it is not guaranteed that the compound string returned is byte-for-byte the same as the string given to the widget originally." *** XM_STRING_COMPARE == XmStringCompare(): (XM_STRING_COMPARE <xmstring_a> <xmxtring_b>) --> returns T if the two XM_STRING args are "semantically equal", else NIL. A note from the XmStringCompare.3X manual page: "XmStringCompare returns a Boolean value indicating the results of a semantically equivalent comparison of two compound strings. Semantically equivalent means that the strings have the same text components, directions, and separators. If character sets are specified, they must be equal as well. In general, if two compound strings are created with the same (char *) string using XmStringCreateSimple in the same language environment, the compound strings compare as equal. If two compound strings are created with the same (char *) string and the same character set other than XmSTRING_DEFAULT_CHARSET using XmStringCreate, the strings compare as equal. The result of comparing a compound string created with XmStringCreate against a compound string created with XmStringCreateSimple is undefined." *** XM_STRING_CONCAT == XmStringConcat(): (XM_STRING_CONCAT <xmstring_a> <xmstring_b>) --> returns a new XM_STRING which is the concatenation of XM_STRINGs <xmstring_a> and <xmstring_b>. *** XM_STRING_COPY == XmStringCopy(): (XM_STRING_COPY <xmstring>) --> returns a new XM_STRING, a copy of <xmstring> *** XM_STRING_CREATE == XmStringCreate(): (XM_STRING_CREATE <string> [<charset>]) --> returns an XM_STRING version of string <string>. Create a compound string from STRING <text>. Optional argument <charset> is a STRING specifying an XmStringCharSet. If the <charset> argument is omitted, XmSTRING_DEFAULT_CHARSET is used. (Note that calling XM_STRING_CREATE with no <charset> argument is equivalent to calling Motif 1.1's XmStringCreateSimple()). Example values for <charset> would be "", which is equivalent to the C Motif constant XmSTRING_DEFAULT_CHARSET; another typical value is "ISO8859-1", which is equivalent to the C Motif constants XmSTRING_ISO8859_1, XmSTRING_OS_CHARSET, and XmFALLBACK_CHARSET. For Motif 1.1, potential values for <charset> are: "" (default) "ISO8859-1" "ISO8859-2" "ISO8859-3" "ISO8859-4" "ISO8859-5" "ISO8859-6" "ISO8859-7" "ISO8859-8" "ISO8859-9" "JISX0201.1976-0" "GB2312.1980-0" "GB2312.1980-1" "JISX0208.1983-0" "JISX0208.1983-1" "KSC5601.1987-0" "KSC5601.1987-1" *** XM_STRING_CREATE_L_TO_R == XmStringCreateLtoR(): (XM_STRING_CREATE_L_TO_R <text> [<charset>]) --> returns an XM_STRING version of string <text>. Create a left-to-right compound string from STRING <text>. This function imposes the semantic of scanning for \n characters in the text. When one is found, the text up to that point is put into a segment followed by a separator component. No final separator component is appended to the end of the compound string. The direction defaults to left-to-right. This function assumes that the encoding is single octet rather than double octet per character of text. Optional argument <charset> is a STRING specifying an XmStringCharSet. If the <charset> argument is omitted, XmSTRING_DEFAULT_CHARSET is used. Example values for <charset> would be "", which is equivalent to the C Motif constant XmSTRING_DEFAULT_CHARSET; another typical value is "ISO8859-1", which is equivalent to the C Motif constants XmSTRING_ISO8859_1, XmSTRING_OS_CHARSET, and XmFALLBACK_CHARSET. For Motif 1.1, other potential values for <charset> are: "" "ISO8859-1" "ISO8859-2" "ISO8859-3" "ISO8859-4" "ISO8859-5" "ISO8859-6" "ISO8859-7" "ISO8859-8" "ISO8859-9" "JISX0201.1976-0" "GB2312.1980-0" "GB2312.1980-1" "JISX0208.1983-0" "JISX0208.1983-1" "KSC5601.1987-0" "KSC5601.1987-1" Note that there also exists a Motif function XmStringLtoRCreate() -- at the time of this writing XmStringCreateLtoR() and XmStringLtoRCreate() are the same, therefore I'm only providing WINTERP primitive XM_STRING_CREATE_L_TO_R. *** XM_STRING_DIRECTION_CREATE == XmStringDirectionCreate(): (XM_STRING_DIRECTION_CREATE :STRING_DIRECTION_L_TO_R) --> returns an XM_STRING with a single L->R direction component. (XM_STRING_DIRECTION_CREATE :STRING_DIRECTION_R_TO_L) --> returns an XM_STRING with a single R->L direction component *** XM_STRING_EMPTY == XmStringEmpty(): (XM_STRING_EMPTY <xmstring>) --> returns T if all segments in XM_STRING <xmstring> are zero length or if there are no text segments. Otherwise returns NIL. *** XM_STRING_GET_L_TO_R == XmStringGetLtoR(): (XM_STRING_GET_L_TO_R <xmstring> [<charset>]) --> returns a STRING, or NIL if no matching character set found. This function will fetch the first text segment of the XM_STRING <xmstring> which matches the character set <charset>, and returns that as a STRING. Optional argument <charset> is a STRING specifying an XmStringCharSet. If the <charset> argument is omitted, XmSTRING_DEFAULT_CHARSET is used. Example values for <charset> would be "", which is equivalent to the C Motif constant XmSTRING_DEFAULT_CHARSET; another typical value is "ISO8859-1", which is equivalent to the C Motif constants XmSTRING_ISO8859_1, XmSTRING_OS_CHARSET, and XmFALLBACK_CHARSET. For Motif 1.1, potential values for <charset> are: "" (default) "ISO8859-1" "ISO8859-2" "ISO8859-3" "ISO8859-4" "ISO8859-5" "ISO8859-6" "ISO8859-7" "ISO8859-8" "ISO8859-9" "JISX0201.1976-0" "GB2312.1980-0" "GB2312.1980-1" "JISX0208.1983-0" "JISX0208.1983-1" "KSC5601.1987-0" "KSC5601.1987-1" #ifdef MOTIF_1.1 *** XM_STRING_HAS_SUBSTRING == XmStringHasSubstring() [Motif 1.1 only]: (XM_STRING_HAS_SUBSTRING <xmstring> <xmsubstring>) --> returns T if XM_STRING <xmsubstring> is a substring of XM_STRING <xmstring>, else returns NIL. #endif /* MOTIF_1.1 */ *** XM_STRING_LENGTH == XmStringLength(): (XM_STRING_LENGTH <xmstring>) --> returns a FIXNUM representing the number of bytes in <xmstring> including all tags, direction indicators, and separators. 0 is returned if the compound string has an invalid structure. *** XM_STRING_LINE_COUNT == XmStringLineCount(): (XM_STRING_LINE_COUNT <xmstring>) --> returns a FIXNUM representing the number of lines in XM_STRING <xmstring>. The effect of XM_STRING_LINE_COUNT is to count lines in the XM_STRING argument. Actually, it returns the number of separators plus one... *** XM_STRING_SEGMENT_CREATE == XmStringSegmentCreate(): (XM_STRING_SEGMENT_CREATE <text> [<charset>] <direction> <separator_p>) --> returns a XM_STRING with the specified components: <text>, a STRING; <charset>, an optional STRING specifying a character set <direction>, a symbol, either :STRING_DIRECTION_L_TO_R, or :STRING_DIRECTION_R_TO_L; <separator_p>, a boolean; if non-NIL, a separator will be added immediately following the <text> component. For Motif 1.1, potential values for <charset> are: "" (default) "ISO8859-1" "ISO8859-2" "ISO8859-3" "ISO8859-4" "ISO8859-5" "ISO8859-6" "ISO8859-7" "ISO8859-8" "ISO8859-9" "JISX0201.1976-0" "GB2312.1980-0" "GB2312.1980-1" "JISX0208.1983-0" "JISX0208.1983-1" "KSC5601.1987-0" "KSC5601.1987-1" *** XM_STRING_SEPARATOR_CREATE == XmStringSeparatorCreate(): (XM_STRING_SEPARATOR_CREATE) --> returns an XM_STRING with a single component, a separator. ============================================================================== * Future work, missing features. If you add any of the features described below, please send your modifications to me at mayer@hplabs.hp.com or hplabs!mayer. ** Support for Multiple Displays. The X11r3 toolkit upon which Motif 1.0 is based does not support multiple displays properly, and therefore Motif 1.0 does not support multiple displays either. The X11r4 Xtoolkit supposedly supports multiple displays, so we might expect bug-free multiple display support in Motif 1.1 (??). Eventually, I hope to update WINTERP to support multiple display. ** <Xm/CutPaste.h> -- XmClipboard functionality. The following Motif functionality is missing from WINTERP I didn't get around to adding these due to lack of time and interest. I'm sure I'll be needing this functionality eventually, so you can expect that they'll be included in a future WINTERP release. Feel free to interface these functions and send me your code! XmClipboardBeginCopy(), XmClipboardStartCopy(), XmClipboardCopy(), XmClipboardEndCopy(), XmClipboardCancelCopy(), XmClipboardCopyByName(), XmClipboardUndoCopy(), XmClipboardLock(), XmClipboardUnlock(), XmClipboardStartRetrieve(), XmClipboardRetrieve(), XmClipboardEndRetrieve(), XmClipboardInquireCount(), XmClipboardInquireFormat(), XmClipboardInquireLength(), XmClipboardInquirePendingItems(), XmClipboardWithdrawFormat(), XmClipboardRegisterFormat(). ** <X11/Selection.h> -- X11r3 selection capabilities. The following Motif functionality is missing from WINTERP I didn't get around to adding these due to lack of time and interest. Are these really necessary if we interface XmClipboard?? XtOwnSelection(), XtDisownSelection(), XtGetSelectionValue(), XtGetSelectionValues(), XtSetSelectionTimeout(), XtGetSelectionTimeout(). ** <X11/Protocols.h> -- Window Manager Protocol interfaces. The following Motif functionality is missing from WINTERP I didn't get around to adding these due to lack of time and interest. XmAddWMProtocols(), XmRemoveWMProtocols(), XmAddWMProtocolCallback(), XmRemoveWMProtocolCallback(), XmActivateWMProtocol(), XmDeactivateWMProtocol(), XmSetWMProtocolHooks(), XmAddProtocols(), XmRemoveProtocols(), XmAddProtocolCallback(), XmRemoveProtocolCallback(), XmActivateProtocol(), XmDeactivateProtocol(), XmSetProtocolHooks() ** <X11/PassivGrab.h> The following Motif functionality is missing from WINTERP I didn't get around to adding these due to lack of time and interest. Using these with Motif could cause problems anyways. XtGrabKey(), XtUngrabKey(), XtGrabKeyboard(), XtUngrabKeyboard() ** XtAddInput()/XtRemoveInput(): It might be nice provide some high-level Lisp interfaces that use XtAddInput(): One interface would allow for functionality similar to gnuemacs' "process-sentinel" capabilities but using XtAddInput() for proper integration into the Xtoolkit's event-driven style. This would give WINTERP the ability to concurrently run a subprocess while still responding to Lisp and X events. (In contrast to POPEN and SYSTEM, which cause WINTERP to block until the subprocess terminates) Another high-level interface would allow you to create other TCP, and UDP sockets and attach Lisp code that responds to input on these sockets. ** XtAppAddWorkProc()/XtAppRemoveWorkProc(): This might be useful for scheduling periodic garbage collects that can occur when WINTERP is otherwise idle. ** Missing XmString and XmFontList functionality: XmStringFreeContext(), XmStringGetNextComponent(), XmStringPeekNextComponent(), XmStringGetNextSegment(), XmFontListCreate(), XmStringCreateFontList(), XmFontListFree(), XmFontListAdd(), XmFontListCopy(), XmStringNConcat(), XmStringNCopy(), XmStringBaseline(), XmStringWidth(), XmStringHeight(), XmStringExtent(), XmStringDraw(), XmStringDrawImage(), XmStringDrawUnderline(). If you need any of the above, feel free to add them to ./../src-server/w_XmString.c and send me the changes.... ** More interactive builder-like functions: *** Widget and Resource "palette" It gets tedious having to remember widget class names and resource names. Create a browser that will allow you to visually construct the arguments for widget creation and widget :set_values. Such functionality would serve as the basis for a builder. Much of this could be done in Lisp, without having to modify C code. *** Interactively place a newly created widget inside a manager. *** Interactively move existing widgets around. *** Colorpicker: Be able to mouse on a color-source widget followed by a color-destination widget. The color-destination widget will take on the background/foreground colors of another widget. Allow optional creation of a palette of widgets for picking specific preset color combinations. Both of these could easily be done as Lisp-only extensions to WINTERP. See ./../examples/colorsetr.lsp for a first attempt... *** Resource browser: Be able to bring up a browser that allows you to inspect and alter the resources on a widget. Alterations on a widget are returned as name/value pairs that can be passed on to future invocations of :set_values or :new.